In article <op.u7bfjni44oyyg1@alvarezp-ws>, "Octavio Alvarez" <alvarezp@xxxxxxxxxxxxxxxx> wrote: > On Fri, 29 Jan 2010 13:34:01 -0800, Ron Garret <ron1@xxxxxxxxxxx> wrote: > > > In article <op.u7a909hf4oyyg1@alvarezp-ws>, > > "Octavio Alvarez" <alvarezp@xxxxxxxxxxxxxxxx> wrote: > > > >> On Fri, 29 Jan 2010 12:20:46 -0800, Ron1 <ron1@xxxxxxxxxxx> wrote: > >> > >> It means that if you switch to master^ and commit, your commit will > >> be applied but not tracked (since there is not any branch to advance). > >> > >> You would need to do git checkout -b 'new_branch', and then commit. > >> Now, new_branch will advance with your new commit. > > > > OK, I think I understand that. > > > > Here's the thing: I can do this: > > > > git checkout commit-id filename > > > > and restore a particular revision of a particular file to my working > > tree without affecting my HEAD pointer. I would expect then that > > > > git checkout commit-id > > > > with no filename would do the same thing, except restore the entire tree > > from that commit (including deleting files that didnt' exist then). And > > indeed it does that (or at least appears to -- I haven't explored this > > in depth), except that it DOES move my HEAD pointer to this weird > > non-branch thing. > > I see. You somehow imply that "git checkout commit-id" overlaps with > "git reset --hard commit-id". I'm not intentionally implying that. I don't think git reset --hard does what I want either (but I could be wrong about that). > Even assuming the behavior was not documented in man git-checkout, the > second example looks useless. What is your use case? What would you do > after having all the files in the tree switched to another commit, > without actually updating HEAD to the commit, other than git reset --hard > again or git revert? My actual use case is very complicated, but here's a simplified version: Suppose I'm using git as a back-end for a wiki. I want to look at the state of the entire wiki as it was in some point in the past, and I also want to be able to look at the diffs between individual pages as they were then and as they are now. The most straightforward way I can think of to do that is to simply copy an old commit into my working tree without changing anything else. Then I can look at the old version by simply looking at the files, and I can get the diffs by simply doing a git diff. 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. BTW, it turns out that git checkout [commit] . doesn't do the right thing either. Apparently, it still updates my index, so git diff still doesn't do the right thing. 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