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

[Andrew Eidsness <eclipse@xxxxxxxxxx>]

In my opinion what you've described makes great sense.  To me the value of this change is an easy to understand project
history.  Your sentence with "who cares" makes clear to me the benefit of "Cherry Pick".

-Andrew

On 14-07-09 04:51 PM, Christian W. Damus wrote:
> Hi, Andrew,
> 
> Good point.  In fact, thinking about it now that you have brought my attention to it, I prefer the "Cherry Pick" option.  "Fast Forward Only" would require tedious user intervention in cases where rebase is trivial, such as when the files changed in the Gerrit branch are unmodified on master, but master is ahead by some number of commits that changed other files.  And I don't see the point of the "Rebase if Necessary" option.  The difference between that and cherry-pick is that rebase modifies the source Gerrit review branch whereas the cherry-pick doesn't, but who cares because once the review is submitted, that stream is no longer interesting.  So, you may as well just cherry-pick and be done with it.  :-)   Not only that, but there may be value in keeping the review branch's history intact for later analysis, letting cherry-pick keep a tidy history of *every* branch.
> 
> Does that make sense?  It could be that I'm missing a(nother) subtle distinction between these two options.
> 
> cW
> 
> 
> On Jul 9, 2014, at 4:41 PM, Andrew Eidsness <eclipse@xxxxxxxxxx> wrote:
> 
>> 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
>>>
>>
>> _______________________________________________
>> 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
>