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

[Andrew Eidsness <eclipse@xxxxxxxxxx>]

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
>