Elijah Newren <newren@xxxxxxxxx> 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 (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. > 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.
