Re: master^ is not a local branch -- huh?!?

[Ron Garret <ron1@flownet.com>]

In article <7veil7pgb2.fsf@alter.siamese.dyndns.org>,
 Junio C Hamano <gitster@pobox.com> wrote:

> Ron Garret <ron1@flownet.com> writes:
> 
> >> > > If I do a git reset --hard then I get the old version, but I lose my 
> >> > > HEAD pointer so that git diff doesn't give me what I want any more.
> 
> I think it would be helpful to point out one issue that may hurt you (and
> anybody who thinks "git update --tree" without --index is a good idea).
> 
> Keeping the index and HEAD in sync but matching the work tree files to
> that of a different commit has one major downside.  To git, a work tree
> file that does not exist in the index is a yet-to-be-added-untracked file
> (that is how and why "rm --cached file" works, for example).  It won't
> participate in the diff output (other than being treated as "no such file
> in the work tree version").
> 
> Suppose that you used to have a path in older revision, but not in the
> current revision.  You remove everything from the work tree and replace it
> with the files in the older revision, and you do not touch HEAD nor index.
> "git diff -R" appears to show "what changed since that older version and
> the latest", because it compares what is in the index relative to what is
> in the work tree.  Nice.
> 
> Not quite.  Since the index does not know that path you recently removed,
> you won't see that path.  If you run "git ls-files" for a list of files
> known to git, it wouldn't be shown either.
> 
> Your original "git checkout master^" is a valid and probably the optimal
> way to get a checkout of a older revision (which you could feed to your
> running Lisp interpreter, in addition to being able to run "less" and
> "make" on them).  Exactly because the index is updated to that of the
> older version, you won't lose the sight of the path that you removed in a
> later version, and you can review the change with "git diff -R master".
> 
> I think this is an XY problem that comes from your wanting to use "git
> diff" (compare work tree with index) instead of "git diff $commit", and
> that was because you wanted to use "HEAD" as a name of a commit.  If you
> used a branch name you originally came from, none of this desire to "keep
> index intact" or "keep HEAD intact" would have been necessary.

That's a very good point.

> But this is all tangent; I think you now know more about git to improve
> your IDE integration, without fighting with git but instead taking
> advantage of it.

I hope so :-)

Thanks to everyone who responded in this thread.  It's been very 
educational.  I am very impressed at how supportive this community is to 
a newcomer like me.

rg