Le 29/12/2019 à 18:30, Ian Lance Taylor via gcc a écrit :
On Sun, Dec 29, 2019 at 5:49 AM Julien '_FrnchFrgg_' RIVAUD
<frnchf...@free.fr> wrote:
Which brings me to something I find strange in your policy: to me,
merges from trunk to branches should be rare if not nonexistent. And you
are deciding to banish merges the other way around.
Out of curiosity, why do you say that merges from trunk to branches
should be rare? It seems to me that any long-lived development branch
will require merges from trunk to the branch. Are you saying that
those kinds of branches are rare?
Because in most cases, the development branch should be periodically
rebased on top of master, not use a merge from master to the branch.
Maybe that's easier to do while developping, but in the end a real
rebase should be made (dropping the merge commits), because what you
will send to the ML for review should be a logical stream of changes and
"update" merge commits are not that.
Thankfully, if you have git rerere enabled, most conflict resolutions
you did while merging will be reused when rebasing so it should not be
too painful.
In GCC we have historically had a pattern in which people use
long-lived parallel branches that maintain specific patches on top of
GCC trunk. These branches provide a simple way to get a variant of
GCC with specific patches of interest to some people. These branches
too require regular merges from trunk.
In that case, sure. But I expect these branches to never be merged in
trunk. So the real rule would be « branches that merge from trunk should
not be merged into trunk » (rather than « forbid merges into trunk » or
even « pretend nobody ever merged anything into trunk, these aren't the
droids you are looking for »)
Ian
