Configuration from the outer repo is inherited to the patches repo when --mq is
used.
In case the patches repo only has paths.default configured but the outer repo
has paths.default-push then the inherited default-push will win. Very
confusing.
Inheriting the default paths is however wrong in all sane cases, so now we
explicitly remove them.
The convert extension requires puttags(self, tags) to return a sequence
for a multi-variable assignment. If puttags implicitly returns None,
the code will break when trying to un-pack None for assignment.
The --only-branch option was deprecated in e783d3972bda and --branch
was added instead. But the graphlog extension was not updated to match
the change.
Without this fix, any calls to write_err would go to stdout instead of
stderr, and calls during pushbuffer would cause unpack ValueErrors on
popbuffer.
9af52509546a caused that we find the index of the moving patch in self.series
but look it up in self.full_series. The difference between these is that
full_series also contains comment lines, and we thus moved the wrong patch.
Use back self.full_series to find the moving patch, but take care of striping
the patch guard markers before comparing the patch name. Test cases have been
added for comments and empty lines in self.full_series, and for the case of
guarded patches.
Original patch contributed by Mads Kiilerich <mads@kiilerich.com>
When cloning, prevent [keyword] filename patterns configured locally
in the source directory to persist during the update in the destination.
a) move [keyword] retrieval (back) to reposetup
b) remove the corresponding global kwtools attributes
Add test cases.
(makes issue2135, issue2264 more obvious, but does nothing to fix
either one)
This seems to happen in two distinct cases:
* patch.patch() claims success but changes nothing (e.g.
the transplanted changeset adds an empty file that already
exists)
* patch.patch() makes changes, but repo.status() fails to report them
Both of these seem like bugs in other parts of Mercurial, so arguably
it's not transplant's job to detect the failure to commit. However:
* detecting the problem as soon as possible is desirable
* it prevents a more obscure crash later, in transplants.write()
* there might be other lurking (or future) bugs that cause
repo.commit() to do nothing
Also, in the case of issue2264 (source changesets silently dropped by
transplant), the only way to spot the problem currently is the crash
in transplants.write(). Failure to transplant a patch should abort
immediately, whether it's user error (patch does not apply) or a
Mercurial bug (e.g. repo.status() failing to report changes).
stripping of applied mq patches leads to wrong state recorded in status
file. find all mq patches that will be affected and clean up status file
before strip.
This makes it consistent with dirstate.status(), which is important if
there are other extensions messing with the output of status(). Those
extensions can safely assume that dirstate.status() returns a tuple of
lists, because its docstring says it does. But
inotifystatus.dirstate() returns a list of lists, which can break
those other extensions.
This resolves the issue of hg cmd --mq not being colorized. This was due
to color wrapping only the instance of ui passed to dispatch._runcommand(),
which isn't the same ui object that mq.mqcommand() receives. After dispatch
calls extensions.loadall(), it makes sure any changes to ui.__class__ in
uisetup are propagated.
progress is updated to wrap ui in the same manner because wrapfunction
doesn't play well when ui.__class__ has been replaced by another extension
(orig will point to the old class method instead of color's).
With inotify enabled, files that should be ignored could be detected as
untracked by mercurial. This behavior was wrong because inotify's filestatus
implementation only matched filenames against ignore patterns, instead of
checking if other elements of their paths matched them. This patch fixes the
behavior by checking the file paths against the ignore patterns.
A new test has also been added to the main inotify test to prevent any
regressions.
It seems wiser to reset mq.added at the end of the mq transaction instead of at
the beginning of a qimport call: this way, calling several times qimport()
without saving mq state in-between does not overwrite the previous value of
mq.added (this happens, for example in rebase, where we import several patches
in a batch before calling .save_dirty() )
Clarify that:
- Specified paths are matched by comparing name of file or directory.
- Line order (thus) doesn't matter.
- Rename doesn't imply include.
MQ patch name can contain slashes, e.g. 'foo/bar.patch'.
Currently "qnew foo/bar.patch" works, but
"qrename foo/bar.patch new/dir.patch" fails with
"No such file or directory".
Also added test case for "qnew foo/bar.patch"
Currently, callers of addchangegroup first acquire the repository
lock, usually to check that an unbundle request isn't racing. This
means that changegroup hook actions that might write to a repo get
stuck waiting for a lock. Here, we add a new optional lock parameter
and update all the callers. Post-1.6 we may make it non-optional.
In the case of guarded patch, the patch could not be found because the
full_series list contains also the guard value appended to each patch name.
As we already checked that the patch is pushable above in the code, we just
have to use the series list (which doesn't contains guard value) to get the
patch index.
The 'updating bookmark %s failed!' message is better than
'failed to update bookmark %s'. To have more consistent error
messages we use just 'updating bookmarks %s failed'.
We add a -B/--bookmarks option to hg incmoing and hg outgoing. If the option
is passed we compare bookmarks instead of changesets. This can be used
to see which bookmarks do not exists on the remote site.
