Commit Graph

7 Commits

Author SHA1 Message Date
Martin von Zweigbergk
43fb09f0d0 help: explain that revsets can be used where 1 or 2 revs are wanted
We did not seem to document that one can do things like "hg up :@"
where the last revision of the revset ":@".
2017-01-11 23:13:00 -08:00
Martin von Zweigbergk
1333ea0016 help: explain what the term "revset" means
We refer to revsets in a few places (e.g. in "hg help config"), but we
never explained what they are. Until now.
2017-01-11 22:46:07 -08:00
Martin von Zweigbergk
1840263a8c help: merge revsets.txt into revisions.txt
Selecting single and multiple revisions is closely related, so let's
put it in one place, so users can easily find it. We actually did not
even point to "hg help revsets" from "hg help revisions", but now that
they're on a single page, that won't be necessary.
2017-01-11 11:37:38 -08:00
Martin von Zweigbergk
01bab7fc55 help: use a single paragraph to describe full and abbreviated nodeids
The texts describing 40-digit strings and the abbreviated form are
closely related, so make it a single paragraph.
2017-01-11 11:28:54 -08:00
Mads Kiilerich
1428b73c06 help: branch names primarily denote the tipmost unclosed branch head
Was the behavior correct and the description wrong so it should be updated as
in this patch? Or should the code work as the documentation says?

Both ways could make some sense ... but none of them are obvious in all cases.

One place where it currently cause problems is when the current revision has
another branch head that is closer to tip but closed. 'hg rebase' refuses to
rebase to that as it only see the tip-most unclosed branch head which is the
current revision.

/me kind of likes named branches, but no so much how branch closing works ...
2013-11-21 15:17:18 -05:00
Kevin Bullock
b4041f99fa help: include bookmarks in 'help revisions' and simplify wording 2012-05-16 10:29:11 -05:00
Dan Villiom Podlaski Christiansen
238d382291 setup: install translation files as package data
Remove the `install_package_data' subclass of `install_data' and use
the `package_data' functionality provided by distutils instead. As
package data must be located within the package directory, the data
files are now generated in the build directory.

To simplify the functionality of this change, the top-level `doc' and
`templates' directories have been moved into the `mercurial' package
directory.
2009-12-01 16:06:10 +01:00