Re: [mdt-papyrus.dev] Merge vs. Rebase

[Andrew Eidsness <eclipse@xxxxxxxxxx>]

Has there been any more thought on this?

>From what I've been told, this is just a setting that the Eclipse webmasters can make for the project.  If Gerrit starts
accepting by rebase, the project history will naturally turn into a straight line.

-Andrew

On 14-05-27 05:16 PM, Andrew Eidsness wrote:
> I only have the CDT project to compare with.  In that case all commits are rebased by Gerrit.  In most cases Gerrit is
> able to do the fast-forward if needed.  In a rare case the author or committer needs to manually rebase and update the
> review before it can be committed.
> 
> The process works really well.  I think it might be enforced by a Gerrit setting, but am not positive.
> 
> I can't really think of any other practices that need to be proposed.  Christian has already mentioned that he rebases
> before pushing to Gerrit (I do the same).
> 
> Perhaps other people have ideas or questions.
> 
> -Andrew
> 
> On 14-05-27 07:22 AM, Cedric Dumoulin wrote:
>>
>>   I Andrew,
>>
>>   Thanks for starting the discussion :-).
>>   I think too that we should avoid as much as possible merging nodes in the history. For that, we should favor
>> fast-forward merges and rebasing.
>>
>>   We certainly need to clarify the practices on how Papyrus commiters should retrieve/modify/push code in the Papyrus
>> repository.
>>   Does someone has  good practice(s) to propose ?
>>
>>   Cedric
>>
>>  
>> Andrew Eidsness a écrit :
>>> I haven't seen a discussion about setting up the Papyrus Gerrit to use rebase instead of merge.  I've attached a screen
>>> shot of a typical section of the Papyrus project's history and a screen shot of a typical section of the CDT project's
>>> history.
>>>
>>> The prevelance of merge nodes and the minor parallel streams makes for confusing code archelogical sessions.  This gets
>>> even more complicated when tracking multiple release streams (e.g., master and a maintenance branch).
>>>
>>> The problem is especially visible when contrasted with the CDT's straight-line history.
>>>
>>> These screenshots aren't really a fair comparison; the CDT project is showing twice as much information!  I am tracking
>>> only one remote branch in the Papyrus repo and two in the CDT one.
>>>
>>> I can see why merge nodes might be nice to see your own merge nodes for the past few days development.  However the more
>>> common case is to exploring other people's changes further in the past.  As an example use case, consider investigating
>>> a particular section of code using the annotations.  I don't really care if the code was merged somewhere, what I care
>>> about is the original commit the created the code.
>>>
>>> Does the Papyrus project have any interest in changing from merge-based to rebase-based :-) development?  If this seems
>>> like too radical of a change to make, then what about having a merge-based collector branch that is then rebased into a
>>> straightline onto master?
>>>
>>> -Andrew
>>>
>>>
>>> _______________________________________________
>>> mdt-papyrus.dev mailing list
>>> mdt-papyrus.dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
>>
>>
>>
>> _______________________________________________
>> mdt-papyrus.dev mailing list
>> mdt-papyrus.dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
>>
> 
> _______________________________________________
> mdt-papyrus.dev mailing list
> mdt-papyrus.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
>