hg rollback / hg revert / hg ?? a merge - hg merge could tell it to the user

Angel Ezquerra angel.ezquerra at gmail.com
Sun Jul 8 13:33:25 UTC 2012


On Sun, Jul 8, 2012 at 1:55 PM, Adrian Buehlmann <adrian at cadifra.com> wrote:
> On 2012-07-08 12:48, anatoly techtonik wrote:
>> On Sun, Jul 8, 2012 at 12:30 PM, Adrian Buehlmann <adrian at cadifra.com> wrote:
>>> On 2012-07-08 10:55, anatoly techtonik wrote:
>>>> On Sun, Jul 8, 2012 at 10:26 AM, Adrian Buehlmann <adrian at cadifra.com> wrote:
>>>>> On 2012-07-08 02:41, anatoly techtonik wrote:

[...]

>>> I'm still convinced that help texts need to be read for understanding
>>> what the commands are supposed to do.
>>>
>>> Perhaps, reading a book might also help to get some basic understanding.
>>>
>>> If you don't do that, then you indeed waste your time by just trying out
>>> commands. But then please don't complain.
>>
>> I've read both the book and help at least once. But I don't remember
>> all these gory details, and I don't have time to reread that every
>> time.

I think Adrian has explained everything really well, but let me tell
you the way I see and explain this when I'm asked about it at work.

I think that you give too much meaning to the name "revert" of the
revert command. revert does not mean being able to "undo" anything. It
can only revert, i.e. "change" the contents of files on the working
directory, nothing more, nothing less.

Mercurial repositories have 3 elements:

- The actual repository history (i.e. a DAG or "tree" of revisions),
stored in the .hg folder.
- The working directory (i.e. the files that you see on your file
explorer outside of the .hg folder).
- The current "parent revision" list, which usually points to a single
revision, but after a merge points to 2 revisions (that is in fact the
only case in which the parent revision list points to more than 1
revision). The parent revision links the working directory to the
repository history. It tells mercurial on top of which revision new
commits will be created, and to which revision it must compare the
working directory when you run hg status, etc.

Generally speaking, mercurial core commands modify either the
repository history or the working directory. For example, commit
modifies the repository history, but does not change the working
directory. pull, and push modify the repository history (of the local
or the remote repository), but do not change the working directory. On
the other hand, update, revert and merge change the working directory
but do not change the repository history.

Similarly, some commands modify the parent revisions, but others do
not. There are few commands that _do not_ change the parent revision,
and revert is among them, while update and merge _do_ change the
parent revision.

The following table tries to summarize this for the most common
"active" mercurial commands

        Repository history      Working directory       Parent revision
-----------------------------------------------------------------------
commit          x                                               x
update                                  x                       x
revert                                  x
rollback        x                                               x
merge                                   x                       x
pull            x
push            x

The table only shows "active" commands, i.e. those that modify either
of the 3 elements of the repository (status, diff, annotate, grep, etc
are "passive" because they just show you info, they do not modify the
repo at all)

In the table you can see that the only two commands that modify both
the working directory and the parent revision are merge and update.
This means that update is the only command that could possibly "undo"
everything that merge does. revert on the other hand changes the
working directory but does not change the parent revision. Thus it is
clear that revert _cannot_ be used to "undo" a merge.

Anyway I think that remembering this table helps a lot in
understanding which command must be used at any given time. In fact I
tend to add an additional column to the table, which is whether the
command may need network access or is an strictly local command:

        Repository history      Working directory       Parent
revision     Local command
-----------------------------------------------------------------------------------------
commit          x                                               x
             x
update                                  x                       x
             x
revert                                  x
             x
rollback        x                                               x
             x
merge                                   x                       x
             x
pull            x
push            x

I hope this helps!

Angel



More information about the Mercurial mailing list