Re: Restore a single file in the index back to HEAD

Junio C Hamano [off-list ref] writes:

quoted

I would prefer "git update-index --reset frotz" or "git checkout
--index HEAD frotz". git ls-tree|git update-index is too cryptic for
me and too long for my fingers.

Then perhaps you can use "git checkout HEAD frotz", which is the
simplest?

Sorry, Oops.

One should never respond to a message in an ancient thread
unless one has enough time to revisit previous messages and
refresh one's memory.

The original topic was about updating the index entry without
touching working tree, so "co HEAD path" would not do what was
wanted.

I think at the UI level, the most appropriate place would be
"git reset".  Checkout is a Porcelainish that is primarily about
working tree and it updates the index as a side effect (from the
UI point of view); you can update the working tree without
modifying index or you can update both index and the working
tree, but updating only index and not working tree does not
belong there.

Given a commit that is different from the current HEAD, "reset"
moves the HEAD and depending on hardness of the reset it updates
the index and the working tree.  Currently the command does not
take paths limiters and means "the whole tree", but asking to
update only one would logically fall as a natural extension to
the current command line if we add paths limiters.

As an implementation detail of the new "reset", the ls-tree to
update-index pipe could be used.

Nguyen Thai Ngoc Duy wrote:

On 11/1/06, Junio C Hamano [off-list ref] wrote:

quoted

I think at the UI level, the most appropriate place would be
"git reset".  Checkout is a Porcelainish that is primarily about
working tree and it updates the index as a side effect (from the
UI point of view); you can update the working tree without
modifying index or you can update both index and the working
tree, but updating only index and not working tree does not
belong there.

Then perhaps git-reset should do "co HEAD path" too if --index is not

specified?

To sum up:
 - git reset HEAD path -> git checkout HEAD path
 - git reset --index HEAD path -> git-ls-files HEAD path|git
update-index --index-info
 - git reset HEAD (without path) -> the current behaviour

Because  <commit-ish>  may be missing, there is some ambiguation here.

Currently "git reset --soft <commit-ish>" updates current head only, 
"git reset <commit-ish>" is "git reset --mixed <commit-ish>" and updates
head and index, and "git reset --hard <commit-ish>" updates head, index
and working tree.

The same should be the case for "git reset [--soft|--mixed|--hard]
[<commit-ish>] [--] [paths...]", with the exception that it wouldn't
never update current head. (So --soft with pathspec wouldn't make sense).

On the other hand git-reset is mainly about resetting current head,
so perhaps git-reset isn't the best place to update fragments of index
from HEAD branch.
-- 
Jakub Narebski
ShadeHawk on #git
Poland

Junio C Hamano wrote:

Given a commit that is different from the current HEAD, "reset"
moves the HEAD and depending on hardness of the reset it updates
the index and the working tree.  Currently the command does not
take paths limiters and means "the whole tree", but asking to
update only one would logically fall as a natural extension to
the current command line if we add paths limiters.

As an implementation detail of the new "reset", the ls-tree to
update-index pipe could be used.

 
On the other hand "reset" moves the HEAD, and with pathspec it wouldn't
do that. But there is the same case for "checkout" with pathspec. And this
would make "reset" and "checkout" more similar...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

On 11/1/06, Junio C Hamano [off-list ref] wrote:

Junio C Hamano [off-list ref] writes:

quoted

quoted

I would prefer "git update-index --reset frotz" or "git checkout
--index HEAD frotz". git ls-tree|git update-index is too cryptic for
me and too long for my fingers.

Then perhaps you can use "git checkout HEAD frotz", which is the
simplest?

Sorry, Oops.

One should never respond to a message in an ancient thread
unless one has enough time to revisit previous messages and
refresh one's memory.

The original topic was about updating the index entry without
touching working tree, so "co HEAD path" would not do what was
wanted.

I think at the UI level, the most appropriate place would be
"git reset".  Checkout is a Porcelainish that is primarily about
working tree and it updates the index as a side effect (from the
UI point of view); you can update the working tree without
modifying index or you can update both index and the working
tree, but updating only index and not working tree does not
belong there.

Then perhaps git-reset should do "co HEAD path" too if --index is not specified?
To sum up:
 - git reset HEAD path -> git checkout HEAD path
 - git reset --index HEAD path -> git-ls-files HEAD path|git
update-index --index-info
 - git reset HEAD (without path) -> the current behaviour

Because  <commit-ish>  may be missing, there is some ambiguation here.
--