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

From: Jakub Narebski <jnareb@gmail.com>
Date: Nov 1, 2006, 11:22 UTC
Message-ID: <eia008$aup$1@sea.gmane.org>
In-Reply-To: <fcaeb9bf0611010109t6281a120qeed21e0d3b29ad0c@mail.gmail.com>

Nguyen Thai Ngoc Duy wrote:

> On 11/1/06, Junio C Hamano <junkio@cox.net> wrote:

Show 9 quoted lines

>> 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?

Show 7 quoted lines

> 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