why does backout in this situation need to merge anything?

Wujek Srujek wujek.srujek at gmail.com
Tue Dec 11 20:51:45 UTC 2012


Believe me, I read the docs, but maybe I missed something.
Why doesn't the first backout require a merge, then?

wujek


On Tue, Dec 11, 2012 at 9:14 PM, Bob Hood <bhood2 at comcast.net> wrote:

>  On 12/11/2012 12:57 PM, Wujek Srujek wrote:
>
> Basically, it adds 3 changesets, cset 1 and 2 add some lines, and then
> they are backouted in reverste order. Why does backing out cset 1 require a
> merge?
>
>
> A 'help' of backout suggests that it will, given the right circumstances,
> require a subsequent merge operation:
>
> $ hg help backout
> hg backout [OPTION]... [-r] REV
>
> reverse effect of earlier changeset
>
>     Prepare a new changeset with the effect of REV undone in the current
>     working directory.
>
>
>     If REV is the parent of the working directory, then this new changeset
> is
>     committed automatically. Otherwise, *hg needs to merge the changes
> and the**
> *
> *    merged result is left uncommitted*...
>
>
> Might that explain it?
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20121211/f91b59de/attachment-0002.html>


More information about the Mercurial mailing list