Merge conflicts
233 views
Skip to first unread message
Roland Schulz
Apr 28, 2012, 11:56:46 PM4/28/12
to repo-discuss
Hi,
if a commit cannot be submitted because of merge conflict, one usually does a rebase of the commit. But if the change is a complex merge commit that is difficult. Is it possible to manually merge a commit to resolve the conflict instead of rebasing it?
A related question: We are not using the "Automatically resolve conflicts" option because we would like Jenkins to verify the merge in the case of path conflicts. Is it possible for Gerrit to do an automatic merge ("Automatic resolve conflicts") but not immediately submit it? Instead leave it unsubmitted for review to that Jenkins can verify it?
if a commit cannot be submitted because of merge conflict, one usually does a rebase of the commit. But if the change is a complex merge commit that is difficult. Is it possible to manually merge a commit to resolve the conflict instead of rebasing it?
A related question: We are not using the "Automatically resolve conflicts" option because we would like Jenkins to verify the merge in the case of path conflicts. Is it possible for Gerrit to do an automatic merge ("Automatic resolve conflicts") but not immediately submit it? Instead leave it unsubmitted for review to that Jenkins can verify it?
Thanks
Magnus Bäck
Apr 30, 2012, 9:23:19 AM4/30/12
to repo-d...@googlegroups.com
On Saturday, April 28, 2012 at 23:56 EDT,
rerere feature was enabled when you did the original merge most
subsequent re-merges should be painless. Unless, of course, there have
been upstream changes that affect areas that the merge commit also
changes, but no tricks-up-the-sleave can save you from that.
> A related question: We are not using the "Automatically resolve conflicts"
> option because we would like Jenkins to verify the merge in the case of
> path conflicts. Is it possible for Gerrit to do an automatic merge
> ("Automatic resolve conflicts") but not immediately submit it? Instead
> leave it unsubmitted for review to that Jenkins can verify it?
No, not possible. The rebase feature introduced in Gerrit 2.3 refuses
to rebase merge commits (and making it support merge commits would
probably be difficult), but that feature would otherwise have been a
good choice as I believe it always uses content merging regardless of
the "Automatically resolve conflicts" configuration.
--
Magnus Bäck
ba...@google.com
Roland Schulz <rol...@utk.edu> wrote:
> if a commit cannot be submitted because of merge conflict, one usually
> does a rebase of the commit. But if the change is a complex merge
> commit that is difficult. Is it possible to manually merge a commit
> to resolve the conflict instead of rebasing it?
I don't think there's any better way than redoing the merge. If Git's
> if a commit cannot be submitted because of merge conflict, one usually
> does a rebase of the commit. But if the change is a complex merge
> commit that is difficult. Is it possible to manually merge a commit
> to resolve the conflict instead of rebasing it?
rerere feature was enabled when you did the original merge most
subsequent re-merges should be painless. Unless, of course, there have
been upstream changes that affect areas that the merge commit also
changes, but no tricks-up-the-sleave can save you from that.
> A related question: We are not using the "Automatically resolve conflicts"
> option because we would like Jenkins to verify the merge in the case of
> path conflicts. Is it possible for Gerrit to do an automatic merge
> ("Automatic resolve conflicts") but not immediately submit it? Instead
> leave it unsubmitted for review to that Jenkins can verify it?
to rebase merge commits (and making it support merge commits would
probably be difficult), but that feature would otherwise have been a
good choice as I believe it always uses content merging regardless of
the "Automatically resolve conflicts" configuration.
--
Magnus Bäck
ba...@google.com
Roland Schulz
Apr 30, 2012, 10:35:26 AM4/30/12
to repo-d...@googlegroups.com
On Mon, Apr 30, 2012 at 9:23 AM, Magnus Bäck <ba...@google.com> wrote:
On Saturday, April 28, 2012 at 23:56 EDT,
Roland Schulz <rol...@utk.edu> wrote:I don't think there's any better way than redoing the merge. If Git's
> if a commit cannot be submitted because of merge conflict, one usually
> does a rebase of the commit. But if the change is a complex merge
> commit that is difficult. Is it possible to manually merge a commit
> to resolve the conflict instead of rebasing it?
rerere feature was enabled when you did the original merge most
subsequent re-merges should be painless. Unless, of course, there have
been upstream changes that affect areas that the merge commit also
changes, but no tricks-up-the-sleave can save you from that.
The problem with rerere is that it doesn't reapply changes outside of the conflicting lines.Thus if a merge commit required changes in other lines/files then those have to be redone when redoing the merge.
If one has Merge M1 which is ready for submission but has a merge conflict and M2 which is a merge of M1 and upstream. Then if Gerrit would allow to submit M2 without first trying to merge M1, one could use merge instead of rebase to resolve conflicts. M1 could also be a non-merge commit. But in that case rebase would be easy thus the procedure not useful.
Do you think this would work and would be generally useful? Then I'll open a feature request.
> A related question: We are not using the "Automatically resolve conflicts"No, not possible. The rebase feature introduced in Gerrit 2.3 refuses
> option because we would like Jenkins to verify the merge in the case of
> path conflicts. Is it possible for Gerrit to do an automatic merge
> ("Automatic resolve conflicts") but not immediately submit it? Instead
> leave it unsubmitted for review to that Jenkins can verify it?
to rebase merge commits (and making it support merge commits would
probably be difficult), but that feature would otherwise have been a
good choice as I believe it always uses content merging regardless of
the "Automatically resolve conflicts" configuration.
Do you mean https://gerrit-review.googlesource.com/#/c/32431 with the rebase feature?
This is going to be in 2.4 and not in 2.3, right? At least I cannot see a rebase button in my 2.3 installation. If it is already in 2.3 I would be interested in how to activate it.
Roland
--
Magnus Bäck
ba...@google.com
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
Magnus Bäck
Apr 30, 2012, 10:50:33 AM4/30/12
to repo-d...@googlegroups.com
On Monday, April 30, 2012 at 10:35 EDT,
> If one has Merge M1 which is ready for submission but has a merge
> conflict and M2 which is a merge of M1 and upstream. Then if Gerrit
> would allow to submit M2 without first trying to merge M1, one could
> use merge instead of rebase to resolve conflicts. M1 could also be a
> non-merge commit. But in that case rebase would be easy thus the
> procedure not useful.
>
> Do you think this would work and would be generally useful? Then I'll
> open a feature request.
Are you sure this doesn't work as it is? If you try to submit M2 first
it'll be in the "Submitted, merge pending" state, and submitting M1
afterwards will cause Gerrit to submit M1 and M2 at the same time by
merging from M2. I don't think the mergeability of M1 is even considered
in this case. That said, I've never looked at the code that queues up
changes and submits them in batch.
> > No, not possible. The rebase feature introduced in Gerrit 2.3
> > refuses to rebase merge commits (and making it support merge commits
> > would probably be difficult), but that feature would otherwise have
> > been a good choice as I believe it always uses content merging
> > regardless of the "Automatically resolve conflicts" configuration.
>
> Do you mean https://gerrit-review.googlesource.com/#/c/32431 with the
> rebase feature?
Yes.
> This is going to be in 2.4 and not in 2.3, right? At least I cannot
> see a rebase button in my 2.3 installation. If it is already in 2.3
> I would be interested in how to activate it.
No, you're right. It indeed wasn't included in 2.3.
--
Magnus Bäck
ba...@google.com
Roland Schulz <rol...@utk.edu> wrote:
> On Mon, Apr 30, 2012 at 9:23 AM, Magnus Bäck <ba...@google.com> wrote:
>
> > I don't think there's any better way than redoing the merge. If
> > Git's rerere feature was enabled when you did the original merge
> > most subsequent re-merges should be painless. Unless, of course,
> > there have been upstream changes that affect areas that the merge
> > commit also changes, but no tricks-up-the-sleave can save you from
> > that.
>
> The problem with rerere is that it doesn't reapply changes outside of
> the conflicting lines.Thus if a merge commit required changes in other
> lines/files then those have to be redone when redoing the merge.
Ah, yes. Only conflicting hunks will ever be taken care of by rerere.
> On Mon, Apr 30, 2012 at 9:23 AM, Magnus Bäck <ba...@google.com> wrote:
>
> > I don't think there's any better way than redoing the merge. If
> > Git's rerere feature was enabled when you did the original merge
> > most subsequent re-merges should be painless. Unless, of course,
> > there have been upstream changes that affect areas that the merge
> > commit also changes, but no tricks-up-the-sleave can save you from
> > that.
>
> The problem with rerere is that it doesn't reapply changes outside of
> the conflicting lines.Thus if a merge commit required changes in other
> lines/files then those have to be redone when redoing the merge.
> If one has Merge M1 which is ready for submission but has a merge
> conflict and M2 which is a merge of M1 and upstream. Then if Gerrit
> would allow to submit M2 without first trying to merge M1, one could
> use merge instead of rebase to resolve conflicts. M1 could also be a
> non-merge commit. But in that case rebase would be easy thus the
> procedure not useful.
>
> Do you think this would work and would be generally useful? Then I'll
> open a feature request.
it'll be in the "Submitted, merge pending" state, and submitting M1
afterwards will cause Gerrit to submit M1 and M2 at the same time by
merging from M2. I don't think the mergeability of M1 is even considered
in this case. That said, I've never looked at the code that queues up
changes and submits them in batch.
> > No, not possible. The rebase feature introduced in Gerrit 2.3
> > refuses to rebase merge commits (and making it support merge commits
> > would probably be difficult), but that feature would otherwise have
> > been a good choice as I believe it always uses content merging
> > regardless of the "Automatically resolve conflicts" configuration.
>
> Do you mean https://gerrit-review.googlesource.com/#/c/32431 with the
> rebase feature?
> This is going to be in 2.4 and not in 2.3, right? At least I cannot
> see a rebase button in my 2.3 installation. If it is already in 2.3
> I would be interested in how to activate it.
--
Magnus Bäck
ba...@google.com
Roland Schulz
Apr 30, 2012, 2:30:41 PM4/30/12
to repo-d...@googlegroups.com
On Mon, Apr 30, 2012 at 10:50 AM, Magnus Bäck <ba...@google.com> wrote:
On Monday, April 30, 2012 at 10:35 EDT,
Roland Schulz <rol...@utk.edu> wrote:
> On Mon, Apr 30, 2012 at 9:23 AM, Magnus Bäck <ba...@google.com> wrote:Are you sure this doesn't work as it is? If you try to submit M2 first
> If one has Merge M1 which is ready for submission but has a merge
> conflict and M2 which is a merge of M1 and upstream. Then if Gerrit
> would allow to submit M2 without first trying to merge M1, one could
> use merge instead of rebase to resolve conflicts. M1 could also be a
> non-merge commit. But in that case rebase would be easy thus the
> procedure not useful.
>
> Do you think this would work and would be generally useful? Then I'll
> open a feature request.
it'll be in the "Submitted, merge pending" state, and submitting M1
afterwards will cause Gerrit to submit M1 and M2 at the same time by
merging from M2. I don't think the mergeability of M1 is even considered
in this case. That said, I've never looked at the code that queues up
changes and submits them in batch.
As you described it, it actually already works.
The problem is that it doesn't work if one has already clicked submit for M1. Then Gerrit doesn't try to merge M1+M2 together by merging M2.
Roland
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en
Jay Soffian
May 6, 2012, 9:18:57 AM5/6/12
to Roland Schulz, repo-d...@googlegroups.com
On Mon, Apr 30, 2012 at 10:35 AM, Roland Schulz <rol...@utk.edu> wrote:
> The problem with rerere is that it doesn't reapply changes outside of the
> conflicting lines.Thus if a merge commit required changes in other
> lines/files then those have to be redone when redoing the merge.
You might find this script useful for "rebasing" a merge:
> The problem with rerere is that it doesn't reapply changes outside of the
> conflicting lines.Thus if a merge commit required changes in other
> lines/files then those have to be redone when redoing the merge.
https://gist.github.com/2622264
A bit of explanation. Say you have a merge M1 between master at C1 and
side branch. You publish the merge. In the meantime, someone has
updated master to C2. M1 is no longer a fast-forward. Therefor, you
wish to redo M1 as a merge between side and C2.
But, even though you used rerere, there were some fixups in M1 you
don't which to lose, so you don't want to just throw out M1.
Instead, with M1 checked-out, run the aforelinked script as "remerge C2".
This does a merge of C2 and M1. You'll have to resolve the conflicts
and commit the merge. Now you have M2 on top of M1. Then you run
"finish-merge.sh" (generated by the script), which creates a new
commit, M1' which is has the same metadata as M1, except its first
parent is now C2 and its tree is M2.
You can now publish M1' as a new patch set on top of M1 and it should
be a fast-forward when you submit it. (Unless of course someone has
pushed C3 in which case you get to rinse, wash, and repeat.)
Note that the script leaves you in detached HEAD state. Don't be
surprised by that.
j.
Roland Schulz
May 10, 2012, 2:58:01 PM5/10/12
to Jay Soffian, repo-d...@googlegroups.com
On Sun, May 6, 2012 at 9:18 AM, Jay Soffian <jayso...@gmail.com> wrote:
On Mon, Apr 30, 2012 at 10:35 AM, Roland Schulz <rol...@utk.edu> wrote:
> The problem with rerere is that it doesn't reapply changes outside of the
> conflicting lines.Thus if a merge commit required changes in other
> lines/files then those have to be redone when redoing the merge.
This is an extremely nice script. Thanks!
The only minor issue I see is that, it discards the original merge message. The merge message of the new "rebased" merge is the one of the 2nd merge. It might be nice to cat both merges together.
Roland
j.
Jay Soffian
May 10, 2012, 4:48:19 PM5/10/12
to Roland Schulz, repo-d...@googlegroups.com
On Thu, May 10, 2012 at 2:58 PM, Roland Schulz <rol...@utk.edu> wrote:
>
>> You might find this script useful for "rebasing" a merge:
>>
>> https://gist.github.com/2622264
>
>
> This is an extremely nice script. Thanks!
>
> The only minor issue I see is that, it discards the original merge message.
> The merge message of the new "rebased" merge is the one of the 2nd merge. It
> might be nice to cat both merges together.
It keeps the original merge message. It throws away the message from
>
>> You might find this script useful for "rebasing" a merge:
>>
>> https://gist.github.com/2622264
>
>
> This is an extremely nice script. Thanks!
>
> The only minor issue I see is that, it discards the original merge message.
> The merge message of the new "rebased" merge is the one of the 2nd merge. It
> might be nice to cat both merges together.
the 2nd merge. If you want both you need to adjust the commands that
are piped into commit-tree.
j.
Reply all
Reply to author
Forward
0 new messages