[prev in list] [next in list] [prev in thread] [next in thread]
List: mercurial
Subject: Re: tell update to run only if there are no conflicts
From: Benjamin Fritz <fritzophrenic () gmail ! com>
Date: 2015-04-14 14:25:20
Message-ID: CAMaohifrznXo1fdw3tYu0nx3MLCQDS2JX6uLxw42RBu9zVOVww () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Apr 13, 2015 at 4:22 AM, Lasse Kliemann <lasse@lassekliemann.de>
wrote:
>
> Kastner Masilko, Friedrich <kastner-masilko@at.festo.com> writes:
>
> >> So I would prefer:
> >>
> >> hg pull
> >> hg update --only-if-no-conflicts
> >> hg commit
> >> hg push -f
>
> > What should happen between the second and third line when a conflict
> > arises? Auto-commit and merge triggering, so your third line will
> > commit the merge? Or simply revert cleanly and restore, so your third
> > line will commit the new head?
>
> The second line (update) should progess as far as possbile on the path
> From _parent_ to _tip_. If it has updated to changeset n on that path
> and n+1 causes a conflict, then the working copy should reflect n (plus
> the local changes). Then the local changes are committed by line 3.
>
> By the way, I think this is (roughly) equivalent to first commiting and
> then rebasing the new commit on changeset n.
>
I think it would be far more predictable, with fewer chances of breaking
things, if "hg update --only-if-no-conflicts" was a no-op when conflicts
arise. Then "hg commit" would create a new head with a parent of whatever
the current working copy's parent happens to be.
[Attachment #5 (text/html)]
<div dir="ltr"><br><br>On Mon, Apr 13, 2015 at 4:22 AM, Lasse Kliemann <<a \
href="mailto:lasse@lassekliemann.de" target="_blank">lasse@lassekliemann.de</a>> \
wrote:<br>><br>> Kastner Masilko, Friedrich <<a \
href="mailto:kastner-masilko@at.festo.com" \
target="_blank">kastner-masilko@at.festo.com</a>> writes:<br>><br>> >> \
So I would prefer:<br>> >><br>> >> hg pull<br>> >> hg \
update --only-if-no-conflicts<br>> >> hg commit<br>> >> hg push \
-f<br>><br>> > What should happen between the second and third line when a \
conflict<br>> > arises? Auto-commit and merge triggering, so your third line \
will<br>> > commit the merge? Or simply revert cleanly and restore, so your \
third<br>> > line will commit the new head?<br>><br>> The second line \
(update) should progess as far as possbile on the path<br>> From _parent_ to \
_tip_. If it has updated to changeset n on that path<br>> and n+1 causes a \
conflict, then the working copy should reflect n (plus<br>> the local changes). \
Then the local changes are committed by line 3.<br>><br>> By the way, I think \
this is (roughly) equivalent to first commiting and<br>> then rebasing the new \
commit on changeset n.<br>><br><br><div>I think it would be far more predictable, \
with fewer chances of breaking things, if "hg update \
--only-if-no-conflicts" was a no-op when conflicts arise. Then "hg \
commit" would create a new head with a parent of whatever the current working \
copy's parent happens to be.</div></div>
[Attachment #6 (text/plain)]
_______________________________________________
Mercurial mailing list
Mercurial@selenic.com
http://selenic.com/mailman/listinfo/mercurial
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic