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

[Andrew Eidsness <eclipse@xxxxxxxxxx>]

When I originally posted the question I was comparing to the CDT project.  In that post I had my terminology wrong.
They actually use Cherry-Pick.  Looking at these options I think that one of "Fast Forward Only" or "Rebase if
Necessary" might be better.  I don't quite understand the description of "Rebase if Necessary", it seems to be talking
about rebases as well as merges.

-Andrew

On 14-07-09 11:23 AM, MAGGI Benoit wrote:
> Hi,
> 
> As no one seems to support merge we can try to setup configuration for rebase.
> 
> Here is what says the official documentation:
> https://gerrit-review.googlesource.com/Documentation/project-configuration.html
> 
> Project Options
> 
> Submit Type
> 
> The method Gerrit uses to submit a change to a project can be modified by any project owner through the project console, Projects > List > my/project. The following methods are supported:
> 
> Fast Forward Only
> This method produces a strictly linear history. All merges must be handled on the client, prior to uploading to Gerrit for review.
> To submit a change, the change must be a strict superset of the destination branch. That is, the change must already contain the tip of the destination branch at submit time.
> Merge If Necessary
> This is the default for a new project.
> If the change being submitted is a strict superset of the destination branch, then the branch is fast-forwarded to the change. If not, then a merge commit is automatically created. This is identical to the classical git merge behavior, or git merge --ff.
> Always Merge
> Always produce a merge commit, even if the change is a strict superset of the destination branch. This is identical to the behavior of git merge --no-ff, and may be useful if the project needs to follow submits with git log --first-parent.
> Cherry Pick
> Always cherry pick the patch set, ignoring the parent lineage and instead creating a brand new commit on top of the current branch head.
> When cherry picking a change, Gerrit automatically appends onto the end of the commit message a short summary of the change's approvals, and a URL link back to the change on the web. The committer header is also set to the submitter, while the author header retains the original patch set author.
> Note that Gerrit ignores patch set dependencies when operating in cherry-pick mode. Submitters must remember to submit changes in the right order since inter-change dependencies will not be enforced for them.
> Rebase If Necessary
> If the change being submitted is a strict superset of the destination branch, then the branch is fast-forwarded to the change. If not, then the change is automatically rebased and then the branch is fast-forwarded to the change.
> When Gerrit tries to do a merge, by default the merge will only succeed if there is no path conflict. A path conflict occurs when the same file has also been changed on the other side of the merge.
> 
> If Automatically resolve conflicts is enabled, Gerrit will try to do a content merge when a path conflict occurs.
> 
> 
> Regards,
> Benoit Maggi
> 
> -----Message d'origine-----
> De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
> Envoyé : mercredi 9 juillet 2014 16:25
> À : Papyrus Project list
> Objet : 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
> 
> _______________________________________________
> mdt-papyrus.dev mailing list
> mdt-papyrus.dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
> _______________________________________________
> mdt-papyrus.dev mailing list
> mdt-papyrus.dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
>