Proposal for the transition timetable for the move to GIT

[Julien '_FrnchFrgg_' RIVAUD]

Le 29/12/2019 à 14:26, Segher Boessenkool a écrit :
> Hi!
>
> On Sun, Dec 29, 2019 at 12:42:07PM +0100, Julien '_FrnchFrgg_' RIVAUD wrote:
>> I'm not arguing that you should go that route, it seems a bit extreme to
>> me. But outright refusing merges on the basis they are painful is (if
>> you can accept the strong word) ludicrous.
> They are painful for everyone working with the history later.

I don't think merges make looking at history more or less painful, 
unless you consider projects like git where there are a inordinate 
amount of merges. And even then, I think they have solutions.

>   Something that we do in GCC more often than in most other projects.
I would have expected a lot if not all projects to look often in 
history, at least for projects with significant complexity.
>
> Which is almost *never* the case for GCC, in my opinion.  Almost all
> commits are smallish improvements / bugfixes.
Which are indepenent, clearly.
> Every patch should normally be posted to the mailing lists for review.
> Such patches should be against trunk.  And *that* patch will be approved,
> so *that* is the one you will commit and push upstream eventually.

Indeed, the rebased series would be what is reviewed and pushed 
upstream. Which can be done with a merge commit anyway. I think you 
really should look at the workflow of the git project (and they have 
their share of interdependent strange things that happen too; of course 
less than GCC due to the complexity of the project, but the techniques 
to ensure you don't get bitten by that are the same).

They use merges extensively, and have a very very good track record of 
non-broken master (or at least had last time I looked).

>
> We cannot waste a year on a social experiment.  We can slowly and carefully
> adopt new procedures, certainly.  But anything drastic isn't advisable imo.
>
> Also, many GCC developers aren't familiar with Git at all.  It takes time
> to learn it, and to learn new ways of working.  Small steps are needed.

Of course ! I am not suggesting you change everything. But setting in 
stone hard rules that force the SVN mindset is harmful too.


> Merges aren't scary.  Merges are inconvenient.

No they are not. You are unaccustomed to them, which is different. 
People that only ever used DVCS feel merges are much more natural and 
even productivity increasing. Some even do "bad merges", like "sync from 
trunk" every other commit, which I very much frown against.

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.

Julien