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 - 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