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

From: Ron Garret <ron1@flownet.com>
Date: Jan 29, 2010, 22:47 UTC
Message-ID: <ron1-0EE62E.14474929012010@news.gmane.org>
In-Reply-To: <op.u7bfjni44oyyg1@alvarezp-ws>

In article <op.u7bfjni44oyyg1@alvarezp-ws>,
 "Octavio Alvarez" <alvarezp@alvarezp.ods.org> wrote:

Show 32 quoted lines

> On Fri, 29 Jan 2010 13:34:01 -0800, Ron Garret <ron1@flownet.com> wrote:
> 
> > In article <op.u7a909hf4oyyg1@alvarezp-ws>,
> >  "Octavio Alvarez" <alvarezp@alvarezp.ods.org> wrote:
> >
> >> On Fri, 29 Jan 2010 12:20:46 -0800, Ron1 <ron1@flownet.com> 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).

Show 5 quoted lines

> 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