Re: On-branch topic description support?

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 21, 2022, 17:49 UTC
Message-ID: <220721.86a692tkva.gmgdl@evledraar.gmail.com>
In-Reply-To: <xmqqwnc6idxr.fsf@gitster.g>

On Thu, Jul 21 2022, Junio C Hamano wrote:

Show 22 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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".

Show 8 quoted lines

> 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.