* Track changes across multiple branches, c.f. "p4 interchanges" ?
@ 2021-04-21 9:54 Luke Diamand
2021-04-21 19:05 ` Junio C Hamano
0 siblings, 1 reply; 3+ messages in thread
From: Luke Diamand @ 2021-04-21 9:54 UTC (permalink / raw)
To: git
We're moving over from Perforce to git.
In Perforce we can find out definitively if a given commit is on branchA
but not on branchB.
It doesn't use textual comparisons (c.f. "git change-id") but tracks
which changes are on which branches.
This is invaluable for managing rapidly evolving sets of release branches.
How do I go about doing this in git?
1. Cherry
"git cherry" - but surely once the change gets sufficiently mangled by
conflicts, won't it end up being "lost" ? That has certainly been my
experience in the past.
2. Merge
I could work on feature branches, and then "git merge --no-ff" the
feature branch - but when I do that I end up pulling all the intervening
history over. e.g.
- X - bugfix
/ \
A - B - C - D - E - M main
\
R relbranch
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.
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.
That's possible, but is quite a big change from the current workflow of
working on main and then "p4 integrate" individual changes over.
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?
Thanks!
Luke
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Track changes across multiple branches, c.f. "p4 interchanges" ?
2021-04-21 9:54 Track changes across multiple branches, c.f. "p4 interchanges" ? Luke Diamand
@ 2021-04-21 19:05 ` Junio C Hamano
2021-04-26 21:35 ` Luke Diamand
0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2021-04-21 19:05 UTC (permalink / raw)
To: Luke Diamand; +Cc: git
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Track changes across multiple branches, c.f. "p4 interchanges" ?
2021-04-21 19:05 ` Junio C Hamano
@ 2021-04-26 21:35 ` Luke Diamand
0 siblings, 0 replies; 3+ messages in thread
From: Luke Diamand @ 2021-04-26 21:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-04-26 21:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-21 9:54 Track changes across multiple branches, c.f. "p4 interchanges" ? Luke Diamand
2021-04-21 19:05 ` Junio C Hamano
2021-04-26 21:35 ` Luke Diamand
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).