[cfe-dev] [Openmp-dev] [Github] RFC: linear history vs merge commits

[Tom Stellard via cfe-dev]

On 01/29/2019 02:48 PM, David Greene wrote:
> Tom Stellard via Openmp-dev <openmp-dev at lists.llvm.org> writes:
> 
>> As part of the migration of LLVM's source code to github, we need to update
>> our developer policy with instructions about how to interact with the new git
>> repository.  There are a lot of different topics we will need to discuss, but
>> I would like to start by initiating a discussion about our merge commit
>> policy.  Should we:
>>
>> 1. Disallow merge commits and enforce a linear history by requiring a
>>    rebase before push.
>>
>> 2. Allow merge commits.
>>
>> 3. Require merge commits and disallow rebase before push.
>>
>> I'm going to propose that if we cannot reach a consensus that we
>> adopt policy #1, because this is essentially what we have now
>> with SVN.
> 
> I agree with proposing #1 in general.  It results in a nice clean
> history and will be familiar to everyone working on the project.
> 
> However, there is a place for merge commits.  If there's a bug in a
> release and we want to make a point release, it might make sense to make
> a commit on the release branch and then merge the release branch to
> master in order to ensure the fix lands there as well.  Another option
> is to commit to master first and then cherry-pick to release.  A third
> option is to use the "hotfix branch" method of git flow [1], which would
> result in a merge commit to the release branch and another merge commit
> to master.
> 

Our current bug-fix fix process is to commit to master first and then
cherry-pick to release branches.

> I've seen projects that commit to release first and then merge release
> to master and also projects that commit to master and cherry-pick to
> release.  I personally haven't seen projects employ the git flow hotfix
> branch method rigorously.
> 
> But GitHub is read-only for almost a year, right?  So we really don't
> have to decide this for a while.  I have not tried using the monorepo
> and committing to SVN with it.  How does that work?  What would it do
> with merge commits?
> 

It will be read-only until October 2019, but I think it's important to decide
on this issue early so we have time to research and implement ways to
automatically enforce our policy to make things as smooth as possible
when we do switch.  I really want us to be able to keep our current migration
schedule.

The GettingStarted patch has been updated with instructions for how to use
the new repo: https://llvm.org/docs/GettingStarted.html#checkout-llvm-from-git

-Tom
>                               -David
> 
> [1] https://nvie.com/posts/a-successful-git-branching-model
>