[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 &lt;<a \
href="mailto:lasse@lassekliemann.de" target="_blank">lasse@lassekliemann.de</a>&gt; \
wrote:<br>&gt;<br>&gt; Kastner Masilko, Friedrich &lt;<a \
href="mailto:kastner-masilko@at.festo.com" \
target="_blank">kastner-masilko@at.festo.com</a>&gt; writes:<br>&gt;<br>&gt; &gt;&gt; \
So I would prefer:<br>&gt; &gt;&gt;<br>&gt; &gt;&gt; hg pull<br>&gt; &gt;&gt; hg \
update --only-if-no-conflicts<br>&gt; &gt;&gt; hg commit<br>&gt; &gt;&gt; hg push \
-f<br>&gt;<br>&gt; &gt; What should happen between the second and third line when a \
conflict<br>&gt; &gt; arises? Auto-commit and merge triggering, so your third line \
will<br>&gt; &gt; commit the merge? Or simply revert cleanly and restore, so your \
third<br>&gt; &gt; line will commit the new head?<br>&gt;<br>&gt; The second line \
(update) should progess as far as possbile on the path<br>&gt; From _parent_ to \
_tip_. If it has updated to changeset n on that path<br>&gt; and n+1 causes a \
conflict, then the working copy should reflect n (plus<br>&gt; the local changes). \
Then the local changes are committed by line 3.<br>&gt;<br>&gt; By the way, I think \
this is (roughly) equivalent to first commiting and<br>&gt; then rebasing the new \
commit on changeset n.<br>&gt;<br><br><div>I think it would be far more predictable, \
with fewer chances of breaking things, if &quot;hg update \
--only-if-no-conflicts&quot; was a no-op when conflicts arise. Then &quot;hg \
commit&quot; would create a new head with a parent of whatever the current working \
copy&#39;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