On Thu, Jul 21 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> To steal and amend a diagram from git-merge(1), we now have turned this: >> >> >> A---B---C topic >> / >> X---Y >> \ >> master >> >> Into this: >> >> A---B---C---M topic >> / \ / >> X---Y --------- >> \ >> master > > If you mean your topic have 3 commits, then I think you want the > first parent of M to be Y, not A, but I agree the above arrangement > can also represent what I was discussing. Yes, sorry. The diagram is incorrect, but not the commands I posted, i.e. one of the parents is "master". > The thing is, it is unclear if such an artificial merge is an easy > thing to maintain by individual contributors. "rebase -i" with some > extra options people are not familiar with may be able to reproduce > the topology without losing information after you accumulate more > commits on top of M (e.g. you build D and E on top of M and now you > want to make it A-B-C-D-E merged into Y with M that records the tree > of E; you'd amend M's message to talk also about D and E), but > "it is possible" is different from "people are comfortable doing". Yes, it's magical, but so is an empty commit having a new "CL" meaning. I'd think both would require relevant tooling to be aware of them. But this is worse in that "git rebase" will get rid of it by default. > If M did not have a backpointer to the other parent, and instead > were an empty commit, then you recreated what I wrote in the message > you are responding to. Yes, that's the difference between the two.
