Re: Track changes across multiple branches, c.f. "p4 interchanges" ?

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 21, 2021, 19:05 UTC
Message-ID: <xmqqpmynxxup.fsf@gitster.g>
In-Reply-To: <d9022ce8-2752-db75-f4b7-d5188c41bd90@diamand.org>

Luke Diamand <luke@diamand.org> writes:

> 2. Merge
> ...
> If I do "git merge bugfix" onto relbranch, then as well as getting X,
> I also get B and C, which I don't want.

This won't work exactly for the reason why you want to do #3 below.

Show 16 quoted lines

> 3. Always start from a merge base
>
> I could tell people that if they are making a bugfix that will need to
> go onto multiple branches, that they need to start from some common 
> merge base, and then merge to the final target branches.
> ...
> And invariably people will start out thinking their change is not a
> bugfix, but a new feature, and then find that actually we need the new 
> feature on the release branch.
>
> 4. Use gerrit change-ids
>
> We could adopt gerrit change-ids. It feels like this is kind of a
> kludge, but perhaps it's the only thing that really works?
>
> Is there something better?

Just to throw another in for completeness (not claiming which one is better and which one is worse):

5. Primarily use #3 to merge, but use "cherry-pick -x" when
   replaying a fix that was built on a wrong base, and tweak the
   procedure to find out "is this fix already on branch X?" to also
   pay attention to it.

It is no worse than #4, I would think, as both approaches would need to scan the commit log messages to find the commits that are not in the ancestry chain that participated to the branch.