Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Merge vs. Rebase

Hi, team,

Have we all had a chance to discuss this further?  As a supporter of rebase, I'm interested to hear the arguments for continuing with the current merge strategy.  I haven't a great deal of experience with Gerrit, so doubtless there is much I can learn here.

Thanks,

Christian


On Jun 2, 2014, at 4:01 AM, MAGGI Benoit Intérimaire <Benoit.MAGGI@xxxxxx> wrote:

> Hi, 
> 
> I'm on the pro-rebase side but we got some people pro-merge here, unfortunately they are not available at the moment.
> Can we wait until the end of the week ? 
> 
> Benoit
> 
> -----Message d'origine-----
> De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Andrew Eidsness
> Envoyé : dimanche 1 juin 2014 03:53
> À : mdt-papyrus.dev@xxxxxxxxxxx
> Objet : Re: [mdt-papyrus.dev] Merge vs. Rebase
> 
> 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
>> 
> 
> _______________________________________________
> 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



Back to the top