Re: Bug report: git branch behaves as if --no-replace-objects is passed

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> ... though if we go that route, I suspect we ought to be adding both the
> original _and_ the replacement.

So "branch --contains X" would ask "which of these branches reach X
or its replacement?" and "branch --no-contains X" would ask "which
of these do not reach X nor its replacement?" --- I guess the result
is still internally consistent (meaning: any and all branches fall
into either "--contains X" or "--no-contains X" camp).

> I'm not entirely sure this is a good direction, though.
>
>> and possibly worse, if I create a new branch based on it and use it:
>> 
>>     $ git branch foobar deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
>>     $ git checkout foobar
>>     $ echo stuff >empty
>>     $ git add empty
>>     $ git commit -m more
>> 
>> then it's clear that branch created foobar pointing to the replaced
>> object rather than the replacement object -- despite the fact that the
>> replaced object doesn't even exist within this repo:
>> 
>>     $ git cat-file -p HEAD
>>     tree 18108bae26dc91af2055bc66cc9fea278012dbd3
>>     parent deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
>>     author Elijah Newren <newren@gmail.com> 1617083739 -0700
>>     committer Elijah Newren <newren@gmail.com> 1617083739 -0700
>> 
>>     more
>
> Yeah, that's pretty horrible.

I am not sure.  As you analize below, the replace mechanism is about
telling Git: when anybody refers to deadbeef, use its replacement if
defined instead.

And one of the points in the mechanism is to allow to do so even
retroactively, so the HEAD object there may be referring to deadbeef
that may not exist does not matter, as long as the object that is to
replace deadbeef is available.  If not, that is a repository
corruption.  After all, the commit object you cat-file'ed may have
been created by somebody else in a separate repository that had
deadbeef before they were told by Elijah that the object is obsolete
and to be replaced by something else (Git supports distributed
development) and then pulled into Elijah's repository, and we should
be prepared to seeing "parent deadbeef" in such a commit.  As long as
replacement happens when accessing the contents, that would be OK.

So, I do not see it as "pretty horrible", but I may be missing
something.