Re: Reverting the whole index-base series

Linus Torvalds [off-list ref] 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.

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.

On Sun, 15 Apr 2007, Junio C Hamano wrote:

quoted

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.

Ahh, ok. I was kind of expecting that you'd actually do something at 
"receive-pack" time instead, not at the next commit. That would also solve 
it - just have an option saying "update the working tree when receiving". 

And since I thought that was what you were aiming at, I didn't see why you 
wanted to hide the previous commit in the index..

All clear now. My confusion.

		Linus