[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-papyrus.dev] Merge vs. Rebase
|
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
