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

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