merge stable into default.
authorPierre-Yves David <pierre-yves.david@fb.com>
Wed, 22 Jan 2014 14:30:45 -0800
changeset 787 a9277d11db47
parent 776 7eaad1101242 (current diff)
parent 786 59c78fd80a0b (diff)
child 788 e973dd5bf583
merge stable into default.
--- a/docs/evolve-faq.rst	Mon Jan 20 10:57:10 2014 +0100
+++ b/docs/evolve-faq.rst	Wed Jan 22 14:30:45 2014 -0800
@@ -12,13 +12,12 @@
 
 Just use commit as usual. New changesets will be in the `draft` phase.
 
-Rewrite a changeset: ``amend``
+Rewrite a changeset: ``commit --amend``
 ------------------------------------------------------------
 
-A new command ``hg amend`` is added by the extension. It writes a new
-changeset combining working-directory parent changes and parent. It
-will work on any `draft` or `secret` changeset. It will not work on
-`public` changesets.
+It writes a new changeset combining working-directory parent changes and parent.
+It will work on any `draft` or `secret` changeset. It will not work on `public`
+changesets.
 
 To understand what the result of amend will be I use the two following
 aliases   [#]_::
@@ -29,47 +28,22 @@
     # status what amend will look like
     pstatus=status --rev .^
 
-It takes various options to pick an author, a date, and the branch of the
-result (see ``hg help amend`` for details).
-
 This command can even be invoked on changesets with children, provided
 none are public.
 
-.. note:: As the amend command is very similar to mq's ``qrefresh``, a ``refresh``
-          alias for amend is also available. But note that contrary to
-          ``qrefresh``, ``amend`` does not exclude changes on file not specified
-          on the command line.
-
-          XXX add idank example
-
-
 .. [#] (defined by the evolve extension for you)
 
 
 
-Move a changeset: ``graft``
+Move a changeset: ``grab``
 ------------------------------------------------------------
 
-The graft command introduced in 2.0 allows you to "copy changes from other
-branches onto the current branch".
-
-The graft command has been altered to allow the creation of an
-obsolete marker indicating both the result cset and its source
-(actually recording changeset movements).
-
-This is achieved using a new flag `-O` (or `old-obsolete`) [#]_.
-
+You can use ``hg grab <rev>`` to move a rev at your current location, making the
+old version obsolete.
 
-XXX example
-
-.. warning:: when using graft --continue after conflict resolution you **MUST**
-             pass `-O` or `-o` flag again because they are not saved for now
+.. note:: grab is an alias for ``hg rebase --dest . --rev $@; hg up <result>``
 
 
-.. [#] add this `-O` to graft instead of a dedicated command is probably
-       abusive. But this was very convenient for experimental purposes.
-       This will likely change in non experimental release.
-
 Delete a changeset: ``prune``
 ------------------------------------------------------------
 
@@ -77,7 +51,8 @@
 
 Just use ``hg prune <some-rev>``.
 
-Moving within the history: ``up`` ``gdown`` and ``gup``
+
+Moving within the history: ``gdown`` and ``gup``
 ------------------------------------------------------------
 
 While working on mutable part of the history you often need to move between
@@ -86,6 +61,8 @@
 You just need to use standard update to work with evolve. For convenience, you
 can use ``hg gup`` to move to the child commit or ``hg gdown`` to move to the parent commit.
 
+Those command have ``previous`` and ``next`` alias.
+
 .. note:: Those commands only exist for the convenience of getting qpush and qpop
           feeling back.
 
@@ -94,6 +71,12 @@
 
 You can use ``hg fold`` to collapse multiple changesets in a single one.
 
+It takes two forms:
+
+``hg fold <rev>`` folds everything from you current changeset to `<rev>`
+
+``hg fold -r <revset>`` fold everything changeset matching the revset together.
+
 Getting changes out of a commit
 ------------------------------------------------------------
 
@@ -154,8 +137,8 @@
 
 You can still use rebase to move a whole segment of the changeset graph together.
 
-.. warning:: Beware that rebasing obsolete changesets will result in
-             conflicting versions of the changesets.
+.. warning:: Beware that rebasing changesets already obsolete will likely result in
+             divergent versions of the changesets.
 
 Resolve history troubles: ``evolve``
 ------------------------------------------------------------
@@ -166,8 +149,9 @@
 
 When you are finished amending a given changeset, you will want to
 declare it stable, in other words rebase its former descendants on its
-newest version. This is not done automatically to avoid the
-proliferation of useless hidden changesets.
+newest version.
+
+You can also use evolve to solve `bumped` and `divergent` changeset/
 
 
 Fix my history afterward: ``prune -n``
@@ -176,20 +160,15 @@
 Sometimes you need to create an obsolete marker by hand. This may happen when
 upstream has applied some of your patches for example.
 
-you can use ``hg prune --new <new-changeset> <old-changeset>`` to add obsolete
+you can use ``hg prune <old-changeset> --succ <new-changeset>`` to add obsolete
 marker.
 
-Export to mq: ``synchronize``
-------------------------------------------------------------
-
-Another extension allows to export your changes to mq.
-
 View diff from the last amend
 ------------------------------------------------------------
 
 An ``odiff`` alias have been added by ``enable.sh``
 
-:: 
+::
     [alias]
     odiff = diff --rev 'limit(precursors(.),1)' --rev .
 
@@ -221,9 +200,11 @@
 
 Extinct changesets are hidden using the *hidden* feature of mercurial.
 
-Only ``hg log``, ``hg glog`` and ``hgview`` support it, other
+Only ``hg log`` and ``hgview`` support it, other
 graphical viewer do not.
 
+You can use ``hg log --graph --hidden`` from the command line
+
 
 
 
@@ -232,4 +213,3 @@
 
 
 
-