This patch fixes the following minor problem:
% hg bookmark -r null test
% hg bookmarks
test -1:000000000000
[...]
% hg commit
% hg bookmarks
* test 17:861ce7a241f9
That is: Bookmarks referring to the null revision are always forwarded
to the current revision.
To me, --move sounds like "make an existing bookmark refer to another
revision", but --move currently means "rename an existing bookmark".
This patch renames the switch to --rename to make it easier to
understand.
This enables for example "hg clone --config format.usefncache=0" which
creates a non-fncache repository, which then can be read by Mercurial
versions before 74698d160f52.
Mercurial bookmarks are local moveable pointers to changesets.
If you commit a changeset that is based on a changeset that has a
bookmark on it, the bookmark is forwarded to the new changeset.
Thanks to Ian Dees, Ronny Pfannschmidt for their patches,
Thanks to ronny, tonfa, prianha, mpm, #mercurial for their comments
and their support that helped me to get things done.
changegroup() has a problem when nodes which does not descend from a node
in <bases> are added to remote after the discovery phase.
If that happens, changegroup() won't send the correct set of nodes, ie.
some nodes will be missing.
To correct it we have to find the set of nodes that both remote and self
have (called <common>), and send all the nodes not in <common>.
This fix has some overhead, in the worst case it will re-send a whole branch.
A proper fix to avoid this overhead might be to change the protocol so that
the <common> nodes are sent (instead of the <bases> of the missing nodes).
Changeset 055df4ac4b13 which fixed issue965 (hg clone static-http
does not work for empty repos) broke cloning of repos with old layout
(without store) via static-http.
This fix makes cloning from old-style repositories possible again,
but will not allow cloning of empty old-style repositories as this
can not be detected reliably.
* adds a new entry 'fncache' to '.hg/requires' for new repos
* writes new file '.hg/store/fncache'
* hash-encodes filenames with long paths (issue839)
* encodes Windows reserved filenames (issue793)
When converting git repos, all stuff happening on branches
seems to be ignored.
This is caused by the fact a "git clone" of a remote git
repo has all its branches prefixed with "origin/". By
chance, the "origin/master" branch is always linked to a
local "master" branch. So getheads() returns only the
master head, and it ignores all the other heads.
Make sure getheads() returns all heads, forcing remote
branches to be return by git-rev-parse.
