In article <7veil7pgb2.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Ron Garret <ron1@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html