Displaying multiple synopsis in online help has been broken since Matt
RST refactoring, around 54e90eb99cfa. Rebase help is apparently the only
one using this trick, just drop the second synopsis and assume people
will understand as with graft help.
If patch.patch() reports patched files when applying a changeset and the
following commit says nothing changed, transplant used to abort with a
RuntimeError, assuming something went wrong with patching.
The mismatch is patch.patch() reports patched files, not changed ones.
It could be modified to report changed files but it means duplicating
work from status, may be expensive in the case of binary files, and is
probably not that useful at API level. For instance, if two patches are
applied on the working directory, the outcome may be nothing changed
while each call would have returned modified files. The caller would
have to call status() itself again.
This patch fixes the issue by trusting patching code: if the patch
succeeded and commit reports nothing changed, then nothing changed,
patch() did not "dropped changes on the floor".
"i18n.gettext()" invocation for "editcomment" itself should have
little impact for whole initialization cost of histedit, because it is
already invoked for initialization of the command table entry.
'\n\n' has to be added to the text being edited separately from
"editcomment", because leading 'line feed' characters are not exported
to "hg.pot" file correctly.
Using less -S will hide possibly important information when reviewing a
changeset, e.g. something wrong/dangerous after the 80th column, because
"less" will not give an indication that following characters are hidden.
Before this patch, updating statistics line appears at the bottom of
the examples describing rules to edit history.
But such line never appear in the file describing rules while
histedit-ing, so this patch removes that line from the examples.
Changeset 9467184ce7e7 broke 'outgoing --large'
...
File "hgext\largefiles\lfutil.py", line 56, in findoutgoing
remote.local(), force=force)
File "mercurial\discovery.py", line 31, in findcommonincoming
if not remote.capable('getbundle'):
AttributeError: 'lfilesrepo' object has no attribute 'capable'
This restores the previous functionality, though I'm not sure if there's a
better way to do this- that changeset introduces a hunk in debugdiscovery that
does this:
if not util.safehasattr(remote, 'branches'):
# enable in-client legacy support
remote = localrepo.locallegacypeer(remote.local())
Is there a legacy support issue here too?
Some help topics use "-" for the top level underlining section mark,
but "-" is used also for the top level categorization in generated
documents: "hg.1.html", for example.
So, TOC in such documents contain "sections in each topics", too.
This patch changes underlining section mark in some help topics to
unify section level in generated documents.
After this patching, levels of each section marks are:
level0
""""""
level1
======
level2
------
level3
......
level4
######
And use of section markers in each documents are:
- mercurial/help/*.txt can use level1 or more
(now these use level1 and level2)
- help for core commands can use level2 or more
(now these use no section marker)
- descriptions of extensions can use level2 or more
(now hgext/acl uses level2)
- help for commands defined in extension can use level4 or more
(now "convert" of hgext/convert uses level4)
"Level0" is used as top level categorization only in "doc/hg.1.txt"
and the intermediate file generated by "doc/gendoc.py", so end users
don't see it in "hg help" outoput and so on.
Previously, a copy or a move of a largefile only worked if the cwd was the root
of the repository. The first issue was that the destination path passed to
os.mkdirs() chopped the absolute path to the standin after '.hglf/', which
essentially created a path relative to the repository root. Similarly, the
second issue was that the source and dest paths for copyfile() were relative to
the repo root. This converts these three paths to absolute paths.
Some notable issues, regardless of the directory in which the cp/mv is executed:
1) The copy is not being recorded in lfdirstate, but it is in dirstate for the
standins. I'm not sure if this is by design (i.e. minimal info in lfdirstate).
2) status -C doesn't behave as expected. Using the testcase as an example:
# after mv + ci
$ hg status -C -v --rev '.^' # expected to see 'A' and ' ' lines too
R dira\dirb\largefile
$ hg status -C -v --rev '.^' foo/largefile
# no output # expected to see 'A' and ' ' lines only
$ hg status -C -v --rev '.^' foo/
# no output # expected to see 'A', ' ' and 'R' lines
$ hg status -C -v --rev '.^' ./ # expected to see 'A' and ' ' lines too
R dirb\largefile
$ hg status -C -v --rev '.^' ../.hglf/dira/foo/largefile
A ..\.hglf\dira\foo\largefile
..\.hglf\dira\dirb\largefile # no 'R' expected when new file is specified
$ hg status -C -v --rev '.^' ../.hglf # OK
A ..\.hglf\dira\foo\largefile
..\.hglf\dira\dirb\largefile
R ..\.hglf\dira\dirb\largefile
When running the following actions:
pick 617f94f13c0f 1 +4
drop 888f9082bf99 2 +5
fold 251d831eeec5 3 +6
if the fold fails, is fixed by the user with a new changeset, --continue
will ignore the new revision when generating the fold changelog. This
was caused by --continue detecting new changesets as descendants of the
parent not descendants of changesets in the initial list. In this case,
dropped changesets must be ignored.
Even with the computation fixed, the 'newchildren' list was always
emptied by the filtering loop and passed empty to finishfold().
Note that changesets dropped and recreated identically will still be
missed. This probably cannot be solved but is unlikely to happen.
Other things, like 'newchildren' having multiple heads, should be
checked as well.
An easy way to force this (and cause a traceback) prior to the fix for 3507 was
$ touch large
$ hg add --large large
$ hg ci -m "add"
$ hg remove large
$ touch large
$ hg addremove --config largefiles.patterns=**large
This patch also detected (and corrected) a previous test where a standin got
added as a largefile (without a traceback).
The problem only occurred if a file was removed with 'hg rm' (as opposed to the
OS utilities), and then addremove was run before a commit. Both normal and
large files were affected.
Ensuring that the file exists prior to an lstat() for size seems like the Right
Thing. But oddly enough, the missing file that was causing lstat() to blow up
was a standin when a largefile was removed, which seems fishy, because a standin
should never be added as a largefile. I was then able to get a standin added as
a largefile (whose name is 'large') with
hg addremove --config largefiles.patterns=**large
which also causes a backtrace. That will be fixed next.
The example in comment #9 of the bug writeup must be run exactly- it was the
commit after the rm and prior to the addremove that screwed things up, because
that commit noticed that the largefile was missing, called drop(), and then the
original commit function did nothing (due to the file in the '!' state). The
addremove command properly put it into the 'R' state, but it remained stuck in
that state (because commit insisted 'nothing changed'). Without the commit
prior to addremove, the problem didn't occur.
Maybe this is an indication that lfdirstate needs to take a few more hints from
the regular dirstate, regardless of what _it_ thinks the state is- similar
inconsistency is probably still possible with this patch if the original commit
succeeds but the lfdirstate write fails.
If a file was missing, the missing list contained a path relative to the repo.
When building the matcher from that list, the file name ended up concatenated to
cwd, causing the command to abort with '<file> not under root'. This rebuilds
the missing list with paths relative to cwd.
This change separates peer implementations from the repository implementation.
localpeer currently is a simple pass-through to localrepository, except for
legacy calls, which have already been removed from localpeer. This ensures that
the local client code only uses the most modern peer API when talking to local
repos.
Peers have a .local() method which returns either None or the underlying
localrepository (or descendant thereof). Repos have a .peer() method to return
a freshly constructed localpeer. The latter is used by hg.peer(), and also to
allow folks to pass either a peer or a repo to some generic helper methods.
We might want to get rid of .peer() eventually.
The only user of locallegacypeer is debugdiscovery, which uses it to pose as a
pre-setdiscovery client. But we decided to leave the old API defined in
locallegacypeer for clarity and maybe for other uses in the future.
It might be nice to actually define the peer API directly in peer.py as stub
methods. One problem there is, however, that localpeer implements
lock/addchangegroup, whereas the true remote peers implement unbundle.
It might be desireable to get rid of this distinction eventually.
This introduces a peer method into all repository classes, which currently
simply returns self. It also changes hg.repository so it now raises an
exception if the supplied paths does not resolve to a localrepo or descendant.
Finally, all call sites are changed to use the peer and local methods as
appropriate, where peer is used whenever the code is dealing with a remote
repository (even if it's on local disk).
Another version could have returned a revset expression from
getoutgoing(), but we do not know how many times it will be resolved, so
better do it once explicitely.
When the source repository had a revision renaming "$new -> $old",
but the filemap a "$old -> $new" rename, the converted revision could
use either $new (deleting the file) or $old (keeping the file) when
getting the file data, depending on the lexicographical order of
those names. So the resulting revision would leave some files
untouched (as expected), but delete others arbitrarely.
It was introduced by c094f330c014, returned by asciiformat() but never
read anywhere. 0997c9dc5951 stopped using it completely, and the
graphmod.CHANGESET type is passed through all functions.
This speeds up status on a largefiles repo by synchronizing the largefiles dirstate to the
largefile's mtime upon update, preventing the files from coming back as "unsure" later,
requiring a check of the SHA1 sum.
Before this patch, MQ checks each subrepo synchronizations against the
working directory context, so ".hgsubstate" updating is not imported
into MQ revision correctly in cases below:
- qrefresh when current ".hgsubstate" is already synchronized with
each subrepos: you can reproduce this easily by just twice or more
qrefresh invocations
- qnew just after rollback of commit which updates ".hgsubstate"
This patch resolves this by checking subrepo states against:
- the parent of "qtop" for qrefresh, or
- the parent of working context otherwise
Even though the committed revision contains diff of ".hgsubstate", the
patch file created by qrefresh doesn't contain it, because:
- ".hgsubstate" is not listed up as one of target files of the patch
for reasons below, so diff of ".hgsubstate" is not imported into
patch file
- status of ".hgsubstate" in working directory is usually "clean"
- ".hgsubstate" is not specified explicitly by users
- the patch file is created before commit processing which updates
or creates ".hgsubstate" automatically, so there is no diff for it
at that time
This patch resolves this problem by:
- putting ".hgsubstate" into target list of the patch, if needed:
this allows "patch.diff()" to import diff of ".hgsubstate" into
patch file.
- creating the patch file after commit processing:
this updates ".hgsubstate" before "patch.diff()" invocation.
For the former fixing, this patch introduces "putsubstate2changes()"
to share same implementation with qnew. This is invoked only once per
qnew/qrefresh at most, so there is less performance impact.
This patch also omits "match" argument for "patch.diff()" invocation,
because "patch.diff()" ignores "match" if "changes" is specified.
If ".hgsubstate" is already listed up as one of commit targets, qnew
put diff of ".hgsubstate" twice into the patch file stored under
".hg/patches".
It causes rejections at applying such patches.
Other than the case like in added test script, this can also occur
when qnew is executed just after rolling back the committing updated
".hgsubstate".
This patch checks whether ".hgsubstate" is already listed up as one of
commit targets, and put it into the appropriate list only if it is not
listed up yet.
