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
Roland
-- ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
On Saturday, April 28, 2012 at 23:56 EDT,
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
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.
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:
> > 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
> 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"
> > 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.
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.
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:
> > 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.
> 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.
> 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.
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:
> > 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.
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.
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:
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.
On Sun, May 6, 2012 at 9:18 AM, Jay Soffian <jaysoff...@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.
> You might find this script useful for "rebasing" a merge:
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.
-- ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309
> 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
the 2nd merge. If you want both you need to adjust the commands that
are piped into commit-tree.
