Proposal for the transition timetable for the move to GIT

[Julien "FrnchFrgg" Rivaud]

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
> <frnchfrgg@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
>