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

[Elijah Newren <newren@gmail.com>]

On Tue, Mar 30, 2021 at 4:04 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
> > Your "as long as" is I think the assumption that's violated in the
> > workflow in question.  You may have the replace ref defined, but
> > others don't[1].  Neither party has the actual original deadbeef
> > commit[2].  Having deadbeef in refs/heads/foobar leads eventually to
> > creating commits with deadbeef as an explicit parent, as we discussed
> > above.  While that's internally consistent, as you point out, can you
> > push your new commit elsewhere without pushing the replace refs too?
>
> I think the change to "branch --contains" would be an improvement
> whether you actually have deadbeef or not, but in any case, defining

Great, we agree that branch --contains can be improved.

> (eh, rather, being able to define) a replacement for something you
> do not have is the ultimate source of the problem.  And that "bug"
> has not very much specific to how "branch --contains" should behave.

Okay, perhaps you consider the ability to create a replacement for an
object that doesn't exist as a bug.  How do we handle this bug,
though?  That's not at all clear to me.  Is it documentation updates?
More error messages from various commands?  Code changes to handle
these cases better?  Something else?  This behavior has been allowed
for over a decade, the refs can be created outside of "git replace"
and the replacement mechanism comes with
* documentation claiming there are only two restrictions on
replacement or replaced refs, both bypassable[1]
* documentation claims of robustness for the replace mechanism[2]
* documentation claiming that all non-reachability traversal related
commands will translate replacement refs to the real commit IDs[3]
* user-facing UI to support creating/updating/deleting replace refs

Based on the above, filter-repo has been creating replacement refs for
years now, one for every commit in the repository that wasn't filtered
out.  And I thought it all worked great without any problems, until
the recent report.  I guess I only ever used the old commit IDs to
pass to things like diff, log, etc., and I guess most users either
didn't use the replace refs at all or only used them that way
too...until this week. However, I'm planning to do a very big testcase
of history rewriting (ancient and huge binary blobs) at $DAYJOB later
this year including replace refs for some of the release-team folks,
so I'm kind of concerned about what I need to fix in git or at least
what I need to document.

[1] See the part up to "...There is no other restriction on the
replaced and replacement objects.", from git-replace(1)
[2] "Note that the grafts mechanism is outdated and can lead to
problems...see git-replace(1) for a more flexible and robust system",
from gitrepository-layout(1)
[3] "Replacement references will be used by default by all Git
commands except those doing reachability traversal", from
git-replace(1)

> > Why does `git branch` (in conjunction with one user deciding to fetch
> > replace refs) make it so easy to create a branch that cannot readily
> > be shared with others?
>
> In other words, I do not think it is "git branch" or "git checkout -b"
> that brought your repository into a broken state.  The "replace"
> mechanism may have room for improvement to avoid such a corruption.
>
> IIRC, the original "graft" mechanism did not even have any UI, so it
> was pretty much "you can graft any parent to any child, and if you
> break the repository you can keep both halves".  Now "replace" has a
> dedicated UI component in the form of "git replace" command, we should
> be able to teach it how to record replacement more safely.

I would like to avoid corruption, and I'm happy to have alternate
solutions.  I don't understand how this could be fixed in "git
replace", though, especially since "git replace" was not even invoked
in the real use case under consideration (git filter-repo uses "git
update-ref --stdin" to create the replace objects).

Are there other alternative ways to fix this outside of "git
branch"/"git checkout -b"?

If not, are there technical reasons that "git branch <branchname>
<replace-hash>" and other commands like it could not be adjusted to
write the replacement hash rather than the replaced hash to the new
branch?

Even if there are no alternative fixes and there are technical reasons
that "git branch" and other commands like it cannot be adjusted, I
still feel that translate-old-commit-hashes via
replacement-of-non-existent-commits feature is valuable enough to keep
in filter-repo anyway.  It'd make me a little uneasy, but I'd continue
creating the replace refs and just document the drawbacks in that
scenario.