how to solve a conflicting editing for someone (using backout?), but cannot merge since there is only one head
Uwe Brauer
oub at mat.ucm.es
Fri Jun 23 20:09:03 UTC 2023
>>> "BMJ" == Becker, Mischa J <mischa.becker at kroger.com> writes:
Hi all,
First of all thanks very much to all of your for your proposed solution(s).
I seem now to understand its logic a bit better. I face th situation I
described quite often, since I collaborate with a lot of people that
basically know only
hg commit -m "Message"
hg push
hg fetch
(hg fetch since it is easier for them than hg pull -u and hg merge)
> Even if you create a 2nd head as Rainer suggested, you still have the
> problem that the backout, rev 7, happens later in the tree than rev 6
> so future merges will continue to backout the rev 6 changes.
Aha, I did not realize this,
I tried his solution out but before answering I received your
email, so that might then not be the best solution
> Backing out rev 7 while on rev 9 essentially merges in your changes
> from rev 6. If you don't like it because it doesn't show in the tree
> as a merge,
Right, Pierre-Yves and Mitchell's solution work, but the merge is not
displayed in the graph (and this I don't like)
> then update to rev 7 before backing it out. That both creates a
> new head, so you can merge, AND puts a copy of your rev 6 changes
> after the rev 7 backout so merge won't discard them.
Aha, I would never ever have expected that it makes a difference from
«where» I make a backout, but I have to say I like this solution a lot.
> If you really don't want to back out the backout, the only other
> option I know of is to update to rev 6 and do your own correct merge
> with rev 8. The only difference between your new merge and rev 9
> should be the backout so you can now merge with rev 9 and throw away
> all of its changes.
Well if do this I first create this sort of
graph
@ changeset: 10:6535da53c78e
│╲ tag: tip
│ │ Branch: default
│ │ Author: Uwe Brauer <oub at mat.ucm.es>
│ │ Date: Fri, 23 Jun 2023 19:54:08 +0200
│ │ Phase: draft
│ │ Summary: Merged the conflicting changesets, ignored the backout
│ │
│ │ ○ changeset: 9:74ef1c9b7f02
│ │╱│ Remote_Branch: default/default
│ │ │ Branch: default
│ │ │ Author: Uwe Brauer <oub at mat.ucm.es>
│ │ │ Date: Fri, 23 Jun 2023 19:42:53 +0200
│ │ │ Phase: public
│ │ │ Summary: Automated merge with file:///home/oub/HGTest/Backout/Test/Server
│ │ │
And I have then to merge 9+10 (so this graph looks a bit uglier than
your backout solution.
◍ changeset: 11:8f7c2a5555f4
│╲ tag: tip
│ │ Branch: default
│ │ Author: Uwe Brauer <oub at mat.ucm.es>
│ │ Date: Fri, 23 Jun 2023 19:56:30 +0200
│ │ Phase: draft
│ │ Summary: Merge all heads
│ │
│ ○ changeset: 10:6535da53c78e
│ │╲ Branch: default
│ │ │ Author: Uwe Brauer <oub at mat.ucm.es>
│ │ │ Date: Fri, 23 Jun 2023 19:54:08 +0200
│ │ │ Phase: draft
│ │ │ Summary: Merged the conflicting changesets, ignored the backout
│ │ │
○───┤ changeset: 9:74ef1c9b7f02
│ │ │ Remote_Branch: default/default
│ │ │ Branch: default
│ │ │ Author: Uwe Brauer <oub at mat.ucm.es>
│ │ │ Date: Fri, 23 Jun 2023 19:42:53 +0200
│ │ │ Phase: public
│ │ │ Summary: Automated merge with file:///home/oub/HGTest/Backout/Test/Server
So I summarise.
Just to make clear that, I modified the commands a bit since it is some
time ago, that I sent my question to the list.
So here are the commands I used
1. I create a server repository running (create.sh)
2. Uwe+Bernhard clone it
3. Uwe runs
echo "Uwe: RH is FALSE" >> test.org
hg commit -m "Uwe: Conflict RH is FALSE"
4. Uwe pushes
5. Bernhard runs
echo "Bernhard: RH is TRUE" >> test.org
hg commit -u "Bernhard Riemann <berniegmail.com> " -m "Bernhard, Conflict RH is TRUE"
hg push (will not work)
hg fetch
it fails conflict.
6. Uwe backout his last change set
hg backout -r 6
hg push
7. Bernhard
hg fetch
hg push
8. Uwe:
hg pull -u
and I end up
@ changeset: 9:74ef1c9b7f02
│╲ tag: tip
│ │ Remote_Branch: default/default
│ │ Branch: default
│ │ Author: Uwe Brauer <oub at mat.ucm.es>
│ │ Date: Fri, 23 Jun 2023 19:42:53 +0200
│ │ Phase: public
│ │ Summary: Automated merge with file:///home/oub/HGTest/Backout/Test/Server
│ │
│ ○ changeset: 8:529b1a456787
│ │ Branch: default
│ │ Author: Bernhard Riemann <berniegmail.com>
│ │ Date: Fri, 23 Jun 2023 19:41:19 +0200
│ │ Phase: public
│ │ Summary: Bernhard, Conflict RH is TRUE
│ │
○ │ changeset: 7:31e073727e68
│ │ Branch: default
│ │ Author: Uwe Brauer <oub at mat.ucm.es>
│ │ Date: Fri, 23 Jun 2023 19:42:08 +0200
│ │ Phase: public
│ │ Summary: Backout the conflict about RH
│ │
○ │ changeset: 6:12841e6c7be3
│╱ Branch: default
│ Author: Uwe Brauer <oub at mat.ucm.es>
│ Date: Fri, 23 Jun 2023 19:41:35 +0200
│ Phase: public
│ Summary: Uwe: Conflict RH is FALSE
Pierres-Yves solution
hg backout -r 7
◍ changeset: 10:3ed026f278f9
│ tag: tip
│ Branch: default
│ Author: Uwe Brauer <oub at mat.ucm.es>
│ Date: Fri, 23 Jun 2023 21:51:17 +0200
│ Phase: draft
│ Summary: Merge tip with changeset 31207
│
○ changeset: 9:74ef1c9b7f02
│╲ Remote_Branch: default/default
│ │ Branch: default
│ │ Author: Uwe Brauer <oub at mat.ucm.es>
│ │ Date: Fri, 23 Jun 2023 19:42:53 +0200
│ │ Phase: public
│ │ Summary: Automated merge with file:///home/oub/HGTest/Backout/Test/Server
│ │
I don't like the graph.
Your solution:
Hg up -r 7
hg backout -r 7
creates a head makes a merge possible and ends up with.
changeset: 11:ec803565629c
│╲ tag: tip
│ │ Branch: default
│ │ Author: Uwe Brauer <oub at mat.ucm.es>
│ │ Date: Fri, 23 Jun 2023 21:55:42 +0200
│ │ Phase: draft
│ │ Summary: Merge both conflicting edits
│ │
│ ○ changeset: 10:cab242b7b17a
│ │ Branch: default
│ │ Author: Uwe Brauer <oub at mat.ucm.es>
│ │ Date: Fri, 23 Jun 2023 21:53:20 +0200
│ │ Phase: draft
│ │ Summary: Backed out changeset 31e073727e68
│ │
Your last proposals ends up in this rather ugly graph, I just mentioned.
Thanks again all of your for your help
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: create.sh
Type: text/x-sh
Size: 422 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20230623/73c0076f/attachment-0001.sh>
More information about the Mercurial
mailing list