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

[Luke Diamand <luke@diamand.org>]

On 21/04/2021 19:05, Junio C Hamano wrote:
> 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.
> 
>> 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.

With the gerrit change-id I can enforce that every commit will always 
have a change-id - either a brand new one, or one that's preserved from 
another commit.

If I just rely on people to use "git cherry-pick -x" then they will 
certainly forget, or do it twice, because people make mistakes.