Junio, I've been running "next", because of working on the submodule
stuff.
I just did some trivial kernel stuff: applied seven patches, and tried to
do a "pull". And whoa, that failed. I get this:
[torvalds@woody linux]$ dotest ~/doit
7 patch(es) to process.
.. all apply fine ..
[torvalds@woody linux]$ git pull master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_linus
remote: Generating pack...
...
Unpacking 22 objects
100% (22/22) done
Your index is based on '80584ff3b99c36ead7e130e453b3a48b18072d18' commit, but the branch tip you are on is at '6a04de6dbe1772d98fddf5099738d6f508e86e21'
That "80584ff.." commit is the commit *before* the "dotest", and HEAD is
(correctly) 6a04de.. that is the end result of the "dotest". That "dotest"
thing is just because "git-applymbox" isn't in my brain stem:
[torvalds@woody linux]$ alias dotest
alias dotest='git-applymbox -u'
so it's not actually anything strange.
Doing a "git reset" obviously fixed it, but if I didn't know that you had
been working on that "index BASE" thing, I would have been very worried.
That index base thing is definitely *not* ready for merging into master
yet!
Linus
Linus Torvalds [off-list ref] writes:
That index base thing is definitely *not* ready for merging into master
yet!
I have been thinking about the approach using index-base to
guard against somebody else updating the tip of branch you are
currently on (let's call that "gremlin updates (to the HEAD)"
for lack of better wording). Unlike the earlier cache-tree
based write-tree optimization, it turns out to be an uphill
battle to make it an "opt-in" enhancement [*1*].
This is primarily because updating the branch tip is not tied
closely to writing out a commit, and writing out a commit is not
tied closely to writing out a tree (to be contained in that
commit) out of the index.
If a command creates a commit that has HEAD as a parent, treats
what is in the index as derived from HEAD, and/or modifies the
index and/or HEAD and leaves the index in a state suitable to
create the next commit out of that has the HEAD commit as a
parent, in order to make such a command aware of the index-base
based guard, the rules are:
(1) You are relying on the index to be actually based on the
HEAD you are going to record as one of the parents of the
resulting commit. Hence, you need to make sure the HEAD
agrees with the commit the current index is based on. The
former can be read with 'rev-parse --verify HEAD', and the
latter can be read from the BASE extension ('update-index
--get-base').
The design goal is not to require everybody to be
index-base aware. So if the index does not record BASE,
the check should succeed, assuming the HEAD has not been
moved.
(2) In order to leave the index in a state suitable to create
the next commit out of that has the updated HEAD commit as
a parent, you need to tell the next command that performs
the check (1) which commit the index is based on. Use
'update-index --set-base' to record the commit you think
the index is based on.
The design goal again is not to require everybody to be
index-base aware. Because most basic operations would not
usually move HEAD when they update index, read_cache()
followed by write_cache() can just keep the base if one is
already recorded in the index, but read-tree by default
invalidates the base, as any command that makes the index
based on a different commit needs to lose the base by
default (if the command is updated to be index-base aware,
instead of losing the base, it would record the right base,
of course).
Updating HEAD commit without changing the index can be done in
two ways. Building on top of HEAD (write-tree then commit-tree
then update-ref), or changing the HEAD commit (using
symbolic-ref to switch branches). I do not think there is a
sane way to make this "opt-in", and that is where recently
triggered problems come from (applymbox problem was noticed by
Linus; I have a small patch for contrib/emacs/git.el, git-gui,
quiltimport, and git-svn). If we make symbolic-ref and
update-ref invalidate the base recorded in the index by default
to avoid false positives, that would make the feature "opt-in",
but that would defeat the whole point of detecting gremlin
update, which would update the ref using these exact commands.
Which leads me to conclude that the current approach based on
index-base needs to be rethought. For now, I'll revert the
whole index base series from 'next'; git will remember it if we
need it later ;-).
[Footnote]
*1* Making it an "opt-in" enhancement to optimize write-tree
using cache-tree was simpler, as there was only one place
that actually writes out the contents of the index. When
the command updates paths with well-defined API implemented
in read-cache.c, we can incrementally invalidate the
cache-tree we originally read from the index and write the
modified cache-tree out to keep write-tree optimized. When
keeping track of cache-tree entries and incrementally
invalidating affected paths is more trouble than its worth,
on the other hand, we can just invalidate the cache-tree
upfront. So the commands that do not want to bother
spending cycles to keep cache-tree up-to-date can easily be
prevented from writing out an out-of-sync cache-tree to
confuse later write-tree.
On Sun, 15 Apr 2007, Junio C Hamano wrote:
I have been thinking about the approach using index-base to
guard against somebody else updating the tip of branch you are
currently on (let's call that "gremlin updates (to the HEAD)"
for lack of better wording). Unlike the earlier cache-tree
based write-tree optimization, it turns out to be an uphill
battle to make it an "opt-in" enhancement [*1*].
I never understood what you were trying to do.
The SHA1 doesn't really help.
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.
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..
Linus