Restore a single file in the index back to HEAD

Restore a single file in the index back to HEAD

[Andy Parkins]

Hello,

I have something like this:

# On branch refs/heads/newmaster
# Updated but not checked in:
#   (will commit)
#
#   modified:   oops/file1
#   modified:   good/file2
#   modified:   good/file3
#   modified:   good/file4

i.e. the index has been updated to hold oops/file1

If I then didn't want to commit oops/file1, how do I restore the HEAD 
oops/file1 back to the index without doing a full reset?

What I'm wishing for is a per file reset...

 git-reset --mixed HEAD oops/file1

(I realise that the above is crazy, but I hope it's explaining what I want).

When I do a git checkout -f oops/file1; I get

"git checkout: updating paths is incompatible with switching branches/forcing
Did you intend to checkout 'oops/file1' which can not be resolved as commit?"



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE

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

[Alex Riesen]

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

[Andy Parkins]

On Thursday 2006 October 26 16:42, Alex Riesen wrote:

Thanks for your suggestion.

> Use "git checkout HEAD oops/file1"

This returned:

"git checkout: updating paths is incompatible with switching branches/forcing
Did you intend to checkout 'oops/file1' which can not be resolved as commit?"

I'm not sure that checkout will do what I want anyway because it would 
overwrite the working directory copy of oops/file1.  I want to keep the 
changes but reset the index to have oops/file1 from HEAD.

Maybe I need to say a little more about what I'm trying to do:

I converted a subversion repository to git.  In that repository I maintained 
my own set of patches in one branch against an upstream branch; I'm now using 
git-cherry-pick to pull a subset of those patches onto a new branch against 
the upstream head.  This is all working fine.  The problem is that I've come 
across a patch that should rightly be two patches instead of one.  

So, I cherry-pick a patch, which updates the working directory and index, 
leaving me with...

# On branch refs/heads/newmaster
# Updated but not checked in:
#   (will commit)
#
#   modified:   oops/file1 
#   modified:   good/file2
#   modified:   good/file3
#   modified:   good/file4

Instead, what I would like is

# On branch refs/heads/newmaster
# Updated but not checked in:
#   (will commit)
#
#   modified:   good/file2
#   modified:   good/file3
#   modified:   good/file4
#
# On branch refs/heads/newmaster
# Changed but not updated:
#   (use git-update-index to mark for commit)
#
#   modified:   oops/file1 

I've actually found a way around the problem.  I do git-reset HEAD, which 
restores the index entirely but leaves the working directory.  Then I 
git-update-index the good/* set.  However, it led me to wonder what the 
inverse of git-update-index is.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE

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

[Shawn Pearce]

Andy Parkins <andyparkins@gmail.com> wrote:
> However, it led me to wonder what the inverse of git-update-index is.

git-update-index  :-)

You can use something like:

    git ls-tree HEAD oops/file1 | git update-index --index-info 

to restore the index state of oops/file1.


Which leads us to the always interesting, fun and exciting:

    git ls-tree -r HEAD | git update-index --index-info 

which will undo everything except 'git add' from the index, as
ls-tree -r is listing everything in the last commit.

-- 

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

[Andy Parkins]

On Friday 2006 October 27 08:38, Shawn Pearce wrote:

>     git ls-tree HEAD oops/file1 | git update-index --index-info
>     git ls-tree -r HEAD | git update-index --index-info

Absolute gold.  Exactly what I wanted.  Thanks so much.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE

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

[Andreas Ericsson]

Shawn Pearce wrote:
> Andy Parkins <andyparkins@gmail.com> wrote:
>> However, it led me to wonder what the inverse of git-update-index is.
> 
> git-update-index  :-)
> 
> You can use something like:
> 
>     git ls-tree HEAD oops/file1 | git update-index --index-info 
> 
> to restore the index state of oops/file1.
> 
> 
> Which leads us to the always interesting, fun and exciting:
> 
>     git ls-tree -r HEAD | git update-index --index-info 
> 
> which will undo everything except 'git add' from the index, as
> ls-tree -r is listing everything in the last commit.
> 

... and also shows The Power of the Pipe, which Daniel@google was 
missing in recent versions of git. ;-)

Btw, this is most definitely not a documented thing and requires a bit 
of core git knowledge, so perhaps the "shell-scripts were good for 
hackers to learn what to pipe where" really *is* a very important point.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

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

[Shawn Pearce]

Andreas Ericsson <ae@op5.se> wrote:
> Shawn Pearce wrote:
> >Andy Parkins <andyparkins@gmail.com> wrote:
> >>However, it led me to wonder what the inverse of git-update-index is.
> >
> >git-update-index  :-)
> >
> >You can use something like:
> >
> >    git ls-tree HEAD oops/file1 | git update-index --index-info 
> >
> >to restore the index state of oops/file1.
> >
> >
> >Which leads us to the always interesting, fun and exciting:
> >
> >    git ls-tree -r HEAD | git update-index --index-info 
> >
> >which will undo everything except 'git add' from the index, as
> >ls-tree -r is listing everything in the last commit.
> >
> 
> ... and also shows The Power of the Pipe, which Daniel@google was 
> missing in recent versions of git. ;-)
> 
> Btw, this is most definitely not a documented thing and requires a bit 
> of core git knowledge, so perhaps the "shell-scripts were good for 
> hackers to learn what to pipe where" really *is* a very important point.

Agreed.

I learned that trick while studying the update-index source code
and tried to wrap my tiny little head around the various formats
--index-info accepts and how that code automatically guesses the
correct format.  :-)

Though I have to admit I wipped up a little test repository just
to make sure what I was writing in the email worked properly;
I can't say I've done it myself too many times in the past...

-- 

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

[Alex Riesen]

>> >Which leads us to the always interesting, fun and exciting:
>> >
>> >    git ls-tree -r HEAD | git update-index --index-info
>> >
>> >which will undo everything except 'git add' from the index, as
>> >ls-tree -r is listing everything in the last commit.
>> >
>>
>> ... and also shows The Power of the Pipe, which Daniel@google was
>> missing in recent versions of git. ;-)
>>
>> Btw, this is most definitely not a documented thing and requires a bit
>> of core git knowledge, so perhaps the "shell-scripts were good for
>> hackers to learn what to pipe where" really *is* a very important point.
>
> Agreed.

Still, it is very impressive, it is supported (and will be supported, I assume),
and as such - worth mentioning at least in these examples everyone keeps
dreaming about. Until that happened, why not mention that the output
of "git ls-tree" is compatible with --index-info of "update-index"?

diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index f283bac..0ab9913 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -64,6 +64,8 @@ Output Format

 When the `-z` option is not used, TAB, LF, and backslash characters
 in pathnames are represented as `\t`, `\n`, and `\\`, respectively.
+This output format is compatible with what "--index-info --stdin" of
+git-update-index expects.

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

[Andreas Ericsson]

Alex Riesen wrote:
>>> >Which leads us to the always interesting, fun and exciting:
>>> >
>>> >    git ls-tree -r HEAD | git update-index --index-info
>>> >
>>> >which will undo everything except 'git add' from the index, as
>>> >ls-tree -r is listing everything in the last commit.
>>> >
>>>
>>> ... and also shows The Power of the Pipe, which Daniel@google was
>>> missing in recent versions of git. ;-)
>>>
>>> Btw, this is most definitely not a documented thing and requires a bit
>>> of core git knowledge, so perhaps the "shell-scripts were good for
>>> hackers to learn what to pipe where" really *is* a very important point.
>>
>> Agreed.
> 
> Still, it is very impressive, it is supported (and will be supported, I 
> assume),
> and as such - worth mentioning at least in these examples everyone keeps
> dreaming about. Until that happened, why not mention that the output
> of "git ls-tree" is compatible with --index-info of "update-index"?
> 

+1. Me likes, although I would amend the command-line that Shawn sent 
and describe what it does. Examples > descriptions everywhere else in 
the git docs, so it would be concise to do so.

> diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
> index f283bac..0ab9913 100644
> --- a/Documentation/git-ls-tree.txt
> +++ b/Documentation/git-ls-tree.txt
> @@ -64,6 +64,8 @@ Output Format
> 
> When the `-z` option is not used, TAB, LF, and backslash characters
> in pathnames are represented as `\t`, `\n`, and `\\`, respectively.
> +This output format is compatible with what "--index-info --stdin" of
> +git-update-index expects.
> 
> 
> Author
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se

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

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> Alex Riesen wrote:
>>>> >Which leads us to the always interesting, fun and exciting:
>>>> >
>>>> >    git ls-tree -r HEAD | git update-index --index-info
>>>> >
>>>> >which will undo everything except 'git add' from the index, as
>>>> >ls-tree -r is listing everything in the last commit.
>>>> >
>>>>
>>>> ... and also shows The Power of the Pipe, which Daniel@google was
>>>> missing in recent versions of git. ;-)
>>>>
>>>> Btw, this is most definitely not a documented thing and requires a bit
>>>> of core git knowledge, so perhaps the "shell-scripts were good for
>>>> hackers to learn what to pipe where" really *is* a very important point.
>>>
>>> Agreed.
>>
>> Still, it is very impressive, it is supported (and will be
>> supported, I assume),
>> and as such - worth mentioning at least in these examples everyone keeps
>> dreaming about. Until that happened, why not mention that the output
>> of "git ls-tree" is compatible with --index-info of "update-index"?
>
> +1. Me likes, although I would amend the command-line that Shawn sent
> and describe what it does. Examples > descriptions everywhere else in
> the git docs, so it would be concise to do so.

I do not like the one that does the whole tree that much.  I
would think "git-read-tree -m HEAD" would be simpler and more
efficient if you are reverting the whole tree.

On the other hand, I designed --index-info to be compatible with
ls-tree output (it is not an accident, it was designed).  In

	git ls-tree HEAD frotz | git update-index --index-info

"frotz" part does not have to be the exact path but can be a
directory name.  It means "revert everything in this directory".

This is quite heavy-handed and you would probably want to run
update-index --refresh afterwards.

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

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
> > Alex Riesen wrote:
> >>>> >Which leads us to the always interesting, fun and exciting:
> >>>> >
> >>>> >    git ls-tree -r HEAD | git update-index --index-info
> >>>> >
> >>>> >which will undo everything except 'git add' from the index, as
> >>>> >ls-tree -r is listing everything in the last commit.
> >>>> >
> >>>>
> >>>> ... and also shows The Power of the Pipe, which Daniel@google was
> >>>> missing in recent versions of git. ;-)
> >>>>
> >>>> Btw, this is most definitely not a documented thing and requires a bit
> >>>> of core git knowledge, so perhaps the "shell-scripts were good for
> >>>> hackers to learn what to pipe where" really *is* a very important point.
> >>>
> >>> Agreed.
> >>
> >> Still, it is very impressive, it is supported (and will be
> >> supported, I assume),
> >> and as such - worth mentioning at least in these examples everyone keeps
> >> dreaming about. Until that happened, why not mention that the output
> >> of "git ls-tree" is compatible with --index-info of "update-index"?
> >
> > +1. Me likes, although I would amend the command-line that Shawn sent
> > and describe what it does. Examples > descriptions everywhere else in
> > the git docs, so it would be concise to do so.
> 
> I do not like the one that does the whole tree that much.  I
> would think "git-read-tree -m HEAD" would be simpler and more

Yep, that's what I use... "git-undo-update-index" is
      #!/bin/sh
      git-read-tree -m -i HEAD

   Luben


> efficient if you are reverting the whole tree.
> 
> On the other hand, I designed --index-info to be compatible with
> ls-tree output (it is not an accident, it was designed).  In
> 
> 	git ls-tree HEAD frotz | git update-index --index-info
> 
> "frotz" part does not have to be the exact path but can be a
> directory name.  It means "revert everything in this directory".
> 
> This is quite heavy-handed and you would probably want to run
> update-index --refresh afterwards.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

[Nguyen Thai Ngoc Duy]

On 10/27/06, Junio C Hamano <junkio@cox.net> wrote:
> On the other hand, I designed --index-info to be compatible with
> ls-tree output (it is not an accident, it was designed).  In
>
>         git ls-tree HEAD frotz | git update-index --index-info
>
> "frotz" part does not have to be the exact path but can be a
> directory name.  It means "revert everything in this directory".
>
> This is quite heavy-handed and you would probably want to run
> update-index --refresh afterwards.

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

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

[Junio C Hamano]

"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:

> On 10/27/06, Junio C Hamano <junkio@cox.net> wrote:
>> On the other hand, I designed --index-info to be compatible with
>> ls-tree output (it is not an accident, it was designed).  In
>>
>>         git ls-tree HEAD frotz | git update-index --index-info
>>
>> "frotz" part does not have to be the exact path but can be a
>> directory name.  It means "revert everything in this directory".
>>
>> This is quite heavy-handed and you would probably want to run
>> update-index --refresh afterwards.
>
> 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?

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

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

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

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

[Nguyen Thai Ngoc Duy]

On 11/1/06, Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> >> 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.
-- 

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

[Jakub Narebski]

Nguyen Thai Ngoc Duy wrote:

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

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

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

[Jakub Narebski]

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

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

[Andy Parkins]

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

Doesn't that update the working directory as well as the index?  My original 
question was addressed perfectly with the point at the "--index-info" switch. 
However, before I asked here I was looking at the man page for update-index 
looking for something like

  git-update-index --reset $FILE

I suppose, if it were being implemented it should be

  git-update-index --reset $COMMIT $FILE

Incidentally, this wouldn't be exactly the same as
  
  git-ls-tree $COMMIT $FILE | git-update-index --index-info

because the git-ls-tree version needs to be run from the root of the working 
directory (this bit me when I first ran it) while the 
(imaginary) "git-update-index --reset" would not.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE

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

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

>> Then perhaps you can use "git checkout HEAD frotz", which is the
>> simplest?
>
> Doesn't that update the working directory as well as the
> index?

Yes, sorry, see my other mail.

> (imaginary) "git-update-index --reset" would not.

update-index is a plumbing that is about updating index (hence
its name) and should not care what the HEAD is, and it does not
even have to have _any_ head to do its work, so in that sense,
"update-index --reset" is conceptually a layering violation.

Another possibility is read-tree, which is another plumbing that
is about updating index from an existing tree (or three).  It
does not take paths limiter, so conceptually that is not too
bad.  We _could_ do so if we really wanted to.

But these two commands are meant to be used as building blocks,
so if there are more suitable UI commands at the Porcelain layer
to implement what we want to do without introducing more special
cases to these plumbing commands, I would rather not touch them.

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

[Andy Parkins]

On Wednesday 2006 November 01 08:56, Junio C Hamano wrote:

> update-index is a plumbing that is about updating index (hence
> its name) and should not care what the HEAD is, and it does not
> even have to have _any_ head to do its work, so in that sense,
> "update-index --reset" is conceptually a layering violation.

Of course; I was really only reporting that git-update-index was the place I 
(as a newbie) went looking for this function.

However, from a UI point of view updating the index from HEAD is just as much 
of an update to the index as updating it from the working directory.  When I 
went looking, I had no idea that update-index was plumbing and not porcelain.  
In fact, as it's a regularly used command (git-update-index; git-commit) I'm 
surprised it's classed as plumbing.

> But these two commands are meant to be used as building blocks,
> so if there are more suitable UI commands at the Porcelain layer
> to implement what we want to do without introducing more special
> cases to these plumbing commands, I would rather not touch them.

As I mentioned in my original email, I was wishing for 

 git-reset --mixed HEAD oops/file1

But of course, that doesn't make any sense in the context of of git-reset, 
which is really only a HEAD manipulator with extras.


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIEE

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

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

> As I mentioned in my original email, I was wishing for 
>
>  git-reset --mixed HEAD oops/file1
>
> But of course, that doesn't make any sense in the context of of git-reset, 
> which is really only a HEAD manipulator with extras.

Well, reset historically is _not_ HEAD manipulator.  It is the
primarily Porcelain-ish to recover the index and/or the working
tree that is in an undesired state.

So from that point of view, the above commandline perfectly
makes sense.  However, giving anything but HEAD with path makes
us go "Huh?"  It is unclear what this should mean:

	git-reset [--hard | --mixed] HEAD^ oops/file1

Checkout is a working tree manipulator Porcelain, and as a side
effect it has always updated the index.  So it might make sense
to give --index-only there:

	git checkout --index-only HEAD -- paths...

But from UI and workflow point of view, I think the situation
under discussion is that the user wishes to _recover_ from an
earlier update-index that he did not want to do.  Although
update-index is not designed as a UI but as a plumbing, it has
been used as such (and git-status output even suggests use of
it), so maybe it is not such a bad idea to bite the bullet and
declare that it now _is_ a Porcelain-ish.  Then we can do what
you suggested (with missing <commit> defaulting to HEAD):

	git update-index --reset [<commit>] -- paths...

I am not enthused by this avenue, though.  I'd like to keep low
level plumbing as "tool to do only one thing and one thing well"
and update-index is as low level as you would get.

On the other hand, we already have --again, so maybe we have
already passed the point of no return.  So I am inclined to
agree with your "update-index --reset" approach, unless somebody
else injects sanity into me.

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

[Andy Parkins]

On Wednesday 2006, November 01 18:28, Junio C Hamano wrote:

> So from that point of view, the above commandline perfectly
> makes sense.  However, giving anything but HEAD with path makes
> us go "Huh?"  It is unclear what this should mean:
>
> 	git-reset [--hard | --mixed] HEAD^ oops/file1

I don't understand.  Why wouldn't that mean reset oops/file1 to the state it 
had in HEAD^?

> Checkout is a working tree manipulator Porcelain, and as a side
> effect it has always updated the index.  So it might make sense
> to give --index-only there:
>
> 	git checkout --index-only HEAD -- paths...

I think you're right that this is not the place - git-checkout is what one 
uses to update your working directory, it's only a side-effect that the index 
is updated - or we could argue that it is necessary that the index is updated 
in order that checkout can do it's job.

> On the other hand, we already have --again, so maybe we have
> already passed the point of no return.  So I am inclined to
> agree with your "update-index --reset" approach, unless somebody
> else injects sanity into me.

Actually; you've talked me out of it.   Given that git-reset is already 
porcelain, and none of the solutions are screaming "right"; it seems better 
to slightly bend git-reset than git-update-index.


Andy
-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

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

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

> On Wednesday 2006, November 01 18:28, Junio C Hamano wrote:
>
>> So from that point of view, the above commandline perfectly
>> makes sense.  However, giving anything but HEAD with path makes
>> us go "Huh?"  It is unclear what this should mean:
>>
>> 	git-reset [--hard | --mixed] HEAD^ oops/file1
>
> I don't understand.  Why wouldn't that mean reset oops/file1 to the state it 
> had in HEAD^?

Path limiters everywhere in git means "do this only for paths
that match this pattern, and empty path means the pattern match
every path -- the command's behaviour is not different in any
other aspect between the case you gave no limiter and the case
you gave _all_ paths as limiters".  So the other paths remain as
they were (both index and working tree), and HEAD needs to be
updated to HEAD^ in the above example.

While that perfect makes sense from mechanical point of view, I
am not sure what it _means_ to keep some paths from now
abandoned future while having some other paths reset to the
rewound commit, from the point of view of end-user operation.

In other words, I do not have a good explanation on what "git
reset [--hard|--mixed] <commit> <path>..." does that I can write
in the documentation.

Now I admit I am not the brightest in the git circle, but if I
have trouble understanding what it does, can we expect other
people to grok it?

>> On the other hand, we already have --again, so maybe we have
>> already passed the point of no return.  So I am inclined to
>> agree with your "update-index --reset" approach, unless somebody
>> else injects sanity into me.
>
> Actually; you've talked me out of it.   Given that git-reset is already 
> porcelain, and none of the solutions are screaming "right"; it seems better 
> to slightly bend git-reset than git-update-index.

Well, now I am not sure of anything anymore ;-).

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

[Andy Parkins]

On Wednesday 2006, November 01 20:49, Junio C Hamano wrote:

> >> 	git-reset [--hard | --mixed] HEAD^ oops/file1
> While that perfect makes sense from mechanical point of view, I
> am not sure what it _means_ to keep some paths from now
> abandoned future while having some other paths reset to the
> rewound commit, from the point of view of end-user operation.

Isn't that exactly what the user would be asking for when they are doing a 
per-file reset?  This is a contrived example as git makes it easier to do it 
in far more sensible ways; but I've done this before now in subversion...  
What if I want to try out some radical change?  It goes like this:

x --- y --- z

Where x is some stable commit; y is a load of crazy changes; we discover that 
the crazy changes are all fine except for one, and so want to rollback one 
file, without yet commiting:

 git-reset --hard HEAD^ frotz

Git would get frotz from HEAD^ and write it to the working directory and the 
index (or just index with --mixed).

> In other words, I do not have a good explanation on what "git
> reset [--hard|--mixed] <commit> <path>..." does that I can write
> in the documentation.

 --mixed
   Resets the index but not the working tree (i.e., the changed files are
   preserved but not marked for commit) and reports what has not been
   updated. This is the default action.  If <path> is given then only that
   path will be reset to the state that <path> had in <commit-ish>.  The
   working tree will be untouched.

 --hard
   Matches the working tree and index to that of the tree being switched to.
   Any changes to tracked files in the working tree since <commit-ish> are
   lost.  If <path> is given then only that path will be reset in both the
   working tree and the index to the state that <path> had in <commit-ish>.

> Well, now I am not sure of anything anymore ;-).

I do hope I'm not being presumptuous with all the above.  I feel a bit gobby 
spouting off like I know what I'm talking about.  Especially as I wrote 
absolutely no part of git whatsoever :-)


Andy
-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

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

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

> On Wednesday 2006, November 01 20:49, Junio C Hamano wrote:
>
>> >> 	git-reset [--hard | --mixed] HEAD^ oops/file1
>> While that perfect makes sense from mechanical point of view, I
>> am not sure what it _means_ to keep some paths from now
>> abandoned future while having some other paths reset to the
>> rewound commit, from the point of view of end-user operation.
>
> Isn't that exactly what the user would be asking for when they are doing a 
> per-file reset?  This is a contrived example as git makes it easier to do it 
> in far more sensible ways; but I've done this before now in subversion...  
> What if I want to try out some radical change?  It goes like this:
>
> x --- y --- z

I assume when you do the following operation your .git/HEAD
points at 'y' which is already committed, and 'z' does not exist
yet (it does not come into the scenario you describe below).

> Where x is some stable commit; y is a load of crazy changes;
> we discover that the crazy changes are all fine except for
> one, and so want to rollback one file, without yet commiting:
>
>  git-reset --hard HEAD^ frotz
>
> Git would get frotz from HEAD^ and write it to the working directory and the 
> index (or just index with --mixed).

You forgot to mention at the same time it makes .git/HEAD point
at 'x'.  That's the part I am not so sure about.

Ah (lightbulb goes on).  So after the above reset, you would do
a "git commit" with or without -a to create a fixed-up 'y' that
does not have changes to 'frotz'?

Then it sort of makes sense.  --soft with paths specifier does
not make much sense (paths specifier is a no-op in that case
because --soft does not touch index nor working tree), but I
wonder what workflow --mixed would help.  It resets the index
for frotz from 'x', while your crazy changes of 'y' is still in
the working tree.  You can "git commit" without -a to create the
same fixed-up 'y' that does not have changes to 'frotz', and
then keep working on 'y' to make it into less crazy.

Ok, that workflow certainly makes sense.

>> In other words, I do not have a good explanation on what "git
>> reset [--hard|--mixed] <commit> <path>..." does that I can write
>> in the documentation.
>
>  --mixed
>    Resets the index but not the working tree (i.e., the changed files are
>    preserved but not marked for commit) and reports what has not been
>    updated. This is the default action.  If <path> is given then only that
>    path will be reset to the state that <path> had in <commit-ish>.  The
>    working tree will be untouched.
>
>  --hard
>    Matches the working tree and index to that of the tree being switched to.
>    Any changes to tracked files in the working tree since <commit-ish> are
>    lost.  If <path> is given then only that path will be reset in both the
>    working tree and the index to the state that <path> had in <commit-ish>.

That's the "mechanical point of view only" description I was
afraid of having.  While I think I now see why they can be
useful, we would need to extend the examples section to
demonstrate how they help workflows to readers.

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

[Andy Parkins]

On Wednesday 2006, November 01 22:08, Junio C Hamano wrote:

> > x --- y --- z
>
> I assume when you do the following operation your .git/HEAD
> points at 'y' which is already committed, and 'z' does not exist
> yet (it does not come into the scenario you describe below).

Sorry, yes, it's there merely to get in the way.

> You forgot to mention at the same time it makes .git/HEAD point
> at 'x'.  That's the part I am not so sure about.

Hmmm, no I had imagined that in path mode HEAD would not be updated because 
that would change the whole commit instead of just the particular file.

> Ah (lightbulb goes on).  So after the above reset, you would do
> a "git commit" with or without -a to create a fixed-up 'y' that
> does not have changes to 'frotz'?

That's the one.  It was described in another response as cherry-picking 
content instead of commits.

> Then it sort of makes sense.  --soft with paths specifier does
> not make much sense (paths specifier is a no-op in that case
> because --soft does not touch index nor working tree), but I

Agreed.  --soft + path can't have any effect because it only updates HEAD, 
which has no meaning in reset-path mode.

> Ok, that workflow certainly makes sense.

When this thread gets looked back upon, is it going to be strange that you 
say "yes, making crazy changes makes sense"?  :-)

> That's the "mechanical point of view only" description I was
> afraid of having.  While I think I now see why they can be

I must have a "mechanical point of view" brain.  I can't see any further than 
the gear wheels.



Andy
-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE

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

[Junio C Hamano]

Andy Parkins <andyparkins@gmail.com> writes:

> On Wednesday 2006, November 01 22:08, Junio C Hamano wrote:
>
>> That's the "mechanical point of view only" description I was
>> afraid of having.  While I think I now see why they can be
>
> I must have a "mechanical point of view" brain.  I can't see
> any further than the gear wheels.

I care more about how something is useful than how faithfully
something is implemented to the specification, which in turn
means the specification needs to obviously indicate why it is
useful.

A gadget may pick up a nearby baseball bat and jump up and down
three times while holding it, but I do not want to have a
description about the gadget that just says it is designed to do
that.  I want the the description to be obvious that everybody
who reads it understands why that gadget is useful in what
situations.  That's why I feel the examples need to be extended.

But if I understand correctly, you are suggesting two different
modes of operation, namely, with path limiters HEAD is not
moved?

That is not something other git commands with pathspec does.
Path limiters tell command to "do your thing only for paths that
match these patterns, while you usually handle all paths; your
behaviour shall otherwise not be any different in other aspects
between the case you got no limiter and the case you got _all_
paths as limiters."  So I do not think making path-only mode and
pathless mode behave differently is a good idea from the UI
point of view.

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

[Andy Parkins]

On Wednesday 2006 November 01 23:39, Junio C Hamano wrote:

> That is not something other git commands with pathspec does.
> Path limiters tell command to "do your thing only for paths that
> match these patterns, while you usually handle all paths; your
> behaviour shall otherwise not be any different in other aspects
> between the case you got no limiter and the case you got _all_
> paths as limiters."  So I do not think making path-only mode and
> pathless mode behave differently is a good idea from the UI
> point of view.

Surely if you move HEAD you have implicitly affected every path?  In which 
case what effect did the path limiter have?

Given

 x --- y --- (z--Z)

With z being the index and Z being the working directory - both uncommitted.  
The file foo will be different in x, y, z, and Z.  We decide that z-foo is 
incorrect and that it was right in x; however, there are changes in Z-foo 
that we want to keep.

 git-reset --mixed HEAD^ foo

This would reset z-foo (because --mixed) to its state in HEAD^; i.e. x-foo.  
If HEAD changes as well then all the rest of y will be lost - not just y-foo.  
Remember the original problem was a way of selectively manipulating the index 
without altering the working directory.

I'm perfectly happy if git-reset is not the place to do this, because 
git-reset is only allowed to fiddle with HEAD/index; I moved to git-reset 
only because you mentioned that "reset historically is _not_ HEAD 
manipulator".

I think we're back to square one: there is no appropriate command to take on 
this functionality:

 git-ls-tree HEAD^ foo | git-update-index --index-info

 * git-reset can't have it because it makes no sense to alter HEAD /and/
   revert a file.  It also occurs to me that "git-reset --hard HEAD^ foo"
   (using my suggested git-reset implementation) would be redundant anyway
   because it's the same as "git-checkout -f HEAD^ foo".
 * git-checkout can't have it because it doesn't target the index.
 * git-update-index can't have it because it is plumbing and doesn't know
   about commits, only about objects.

I'm stumped now.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE

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

[Robin Rosenberg]

onsdag 01 november 2006 21:49 skrev Junio C Hamano:
> Andy Parkins <andyparkins@gmail.com> writes:
> > On Wednesday 2006, November 01 18:28, Junio C Hamano wrote:
> >> So from that point of view, the above commandline perfectly
> >> makes sense.  However, giving anything but HEAD with path makes
> >> us go "Huh?"  It is unclear what this should mean:
> >>
> >> 	git-reset [--hard | --mixed] HEAD^ oops/file1
> >
> > I don't understand.  Why wouldn't that mean reset oops/file1 to the state
> > it had in HEAD^?
>
> Path limiters everywhere in git means "do this only for paths
> that match this pattern, and empty path means the pattern match
> every path -- the command's behaviour is not different in any
> other aspect between the case you gave no limiter and the case
> you gave _all_ paths as limiters".  So the other paths remain as
> they were (both index and working tree), and HEAD needs to be
> updated to HEAD^ in the above example.
>
> While that perfect makes sense from mechanical point of view, I
> am not sure what it _means_ to keep some paths from now
> abandoned future while having some other paths reset to the
> rewound commit, from the point of view of end-user operation.
>
> In other words, I do not have a good explanation on what "git
> reset [--hard|--mixed] <commit> <path>..." does that I can write
> in the documentation.

You could refer to git-checkout although checkout doesn't have something 
corresponding to --mixed. The --hard option would correspond to the -f flag 
in checkout.

It is like "cherrypicking" content (not changes) from a particular commit.  

Where did the soft option go? 

Since checkout already does the work.. Is there any need for extending 
git-reset, other than that's where people look for this feature. The man page 
could be extended instead.

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

[Salikh Zakirov]

Junio C Hamano wrote:
> In other words, I do not have a good explanation on what "git
> reset [--hard|--mixed] <commit> <path>..." does that I can write
> in the documentation.

In my humble opinion, git-reset is somewhat overloaded in functionality,
and it takes time to explain its function to git newbies.

Why not split it into two commands, e.g.

  git-rewind for manipulations with HEAD
  git-reset for manipulations with index and working copy only

?

[PATCH] Added description for inverting git-update-index using --index-info

[Andy Parkins]

I wanted to restore a single file from HEAD back to the index; Shawn Pearce
gave me the answer.  git-ls-tree piped to git-update-index --index-info.

This patch adds that answer to the git-update-index documentation.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
 Documentation/git-update-index.txt |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 41bb7e1..5adf717 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -215,6 +215,24 @@ $ git ls-files -s
 100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2	frotz
 ------------
 
+One particular use of --index-info is to reverse the effect of
+"git-update-index frotz":
+
+------------
+git ls-tree HEAD frotz | git update-index --index-info
+------------
+
+This makes the index hold the file frotz from HEAD rather than from the
+working copy.  Similarly:
+
+------------
+git ls-tree -r HEAD | git update-index --index-info
+------------
+
+Will undo everything except "git add" from the index, as
+"git-ls-tree -r" lists everything in the last commit.
+
+
 
 Using "assume unchanged" bit
 ----------------------------
-- 
1.4.3.3.g5bca6