Re: git behaviour question regarding SHA-1 and commits

From: Jeff King <peff@peff.net>
Date: Nov 14, 2011, 11:48 UTC
Message-ID: <20111114114856.GF10847@sigill.intra.peff.net>
In-Reply-To: <7vwrb3l6v2.fsf@alter.siamese.dyndns.org>

On Sun, Nov 13, 2011 at 07:29:05PM -0800, Junio C Hamano wrote:

Show 15 quoted lines

> If the collision is between commit objects, for example, we would write
> the (old) commit object name to the tip of the current branch. Most
> likely, the tree object recorded in the (old) commit would not match the
> tree object your "git commit" wanted to record (otherwise you have hit
> SHA-1 collision twice in a row ;-), which would mean "git status" would
> show that a whole bunch of paths have changed between the HEAD and the
> index. Also "git log" would show the history leading to the (old) commit
> that is likely to be very different from what you would expect immediately
> after committing the collided commit. Of course, you could recover from it
> with "git reset --soft" after finding out what the previous HEAD was from
> the reflog, but it won't be a pleasant experience.
> 
> There can be other kinds of collisions (e.g. your latest commit might have
> collided with an existing blob or tree, in which case it is likely that
> almost nothing would work after finding a blob or tree in HEAD).

You are more likely to just have blobs collide, since we generate many more blobs than commits (each commit should have at least one changed blob, but typically has more).

And in that case, I expect git would silently lose that state. We would fail to write the new blob to the object db, but "git diff" would report nothing, as it would see that the index entry's sha1 is the same as what is in HEAD, and that the file is up to date with respect to the stat information in the index. So if you were to "git checkout", your content would be lost forever. However, if you instead modify the file further, the new content will be kept (and you will get a very confusing diff).

-Peff