Re: Reverting the whole index-base series

From: Junio C Hamano <junkio@cox.net>
Date: Apr 15, 2007, 21:25 UTC
Message-ID: <7vfy712uva.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0704151356450.5473@woody.linux-foundation.org>

Linus Torvalds <torvalds@linux-foundation.org> writes:

> If "next" and "pu" are the same, and you have "next" checked out, and you 
> push into "pu", what happens? Since the two branches were the same, the 
> SHA1 was the same before, so the BASE commit in the index will be the one 
> that is updated.

But it does not matter if "pu" was not checked out. You will be building on top of "next" which was not changed.

Show 7 quoted lines

> The only thing that matters is that if you update the branch that HEAD 
> points to, and then you'd always need to do something special, but I don't 
> see that it has anything to do with what the "BASE" commit was.. It's 
> purely a matter of "what does HEAD point to", independently of the index.
>
> But no, I wasn't following that series, so I probably totally 
> misunderstood what you were going after..

Could be.

The issue in short was about:

	$ git checkout $branch

At this point you think your HEAD is at $branch head, and you are working towards building a commit that has that commit as one of the parents.

Then a gremlin updates the commit HEAD points at. Maybe somebody else pushed into $branch. Or you had another working tree that shares refs (but not index nor HEAD -- perhaps set up with contrib/workdir/git-new-workdir) with this repository and made a commit there by mistake on the branch.

And you try to make a commit.

	$ git commit

The work you did in your repository were mostly based on the contents of the commit you checked out but this "git commit" will create a commit on top of something else (i.e. the one the gremlin updated to).

To detect this case, we needed to record "which commit are we expecting to base the next commit on". The place to record that information does not have to be in the index (I could have picked a separate file .git/current-head-commit and stored the information there), but the index was a convenient place to do so.

So it does not have anything to do with the index, but very much about the HEAD. The problem was about keeping it in sync with what really was going on in the repository / working tree.