For scripting purposes, it can be convenient to get a simple listing of
available queues, without indication of the active one.
--quiet documentation change removed by Patrick Mézard.
Before this change, the command would abort with a not too clear "patch
renametothis does not exist" error.
This change makes:
qimport --existing --name renametothis thatexistingpatch
equivalent to:
qimport --existing thatexistingpatch; qrename thatexistingpatch renametothis
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.
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>
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() )
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"
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.
this helps users to know what kind of option is:
- no value is required(flag option)
- value is required
- value is required, and multiple occurrences are allowed
each kinds are shown as below:
-f --force force push
-e --ssh CMD specify ssh command to use
-b --branch BRANCH [+] a specific branch you would like to push
if one or more 3rd type options are shown, explanation for '[+]' mark
is also shown as footnote.
Some implementations of ui.label() (HTML versions in particular) must escape
the provided text and then markup the text with their tags. When this marked
up text is then passed to ui.write(), we must label the text as 'ui.labeled'
so the implementation knows not to escape it a second time (exposing the initial
markup).
This required the addition of a 'ui.plain' label for text that is purposefully
not marked up.
I was a little pedantic here, passing even ' ' strings to ui.label() when it
would be included with other labeled text in a ui.write() call. But it seemed
appropriate to lean to the side of caution.
Each check is moved under the code handling the relevant option, and
a new one is added for --create. This fixes duplicated entries being
added to the queues list.
Compare this to --force which allows anything to be pushed. With --new-branch,
only changesets to named branches not present on the and changesets not
introducing additional heads on existing branches are allowed.
Developed by
Henrik Stuart <henrik.stuart@edlund.dk>
Sune Foldager <cryo@cyanite.org>
`opts['unified'] = '0'` tries to reduce the number of lines to be
processed by patch.diffstat, but here it does not affect diffopts,
thus it does not make sense.
Instead, we can change `diffopts.context` directly.
Added test case for qdiff --stat.
All callers to localrepo.transaction() must supply a transaction description.
The description and the existing repository tip are then stored
(transactionally) into .hg/undo.desc; where rollback can later find it.
If, on Windows, your repository and working copy are in a reparse point and you
use os.removedirs, you will remove non-empty reparse points, disabling the
reparse point. See @6b1369445b7b.
By overriding ui.write(), ui.write_err(), ui.popbuffer(), and ui.label(),
the color extension can avoid parsing command output and simply colorize
output based on labels.
As before, the color extension provides a list of default colors for
core commands/labels. Other extensions can provide their own defaults by
specifying a colortable dict (similar to cmdtable).
In this process, --color is promoted to a global option and the deprecated
--no-color option is removed.
Since norepo is a string, not a list, the norepo check was matching
command names against any substring in norepo. This fix splits norepo
into a list of commands.
Without -c, it is a no-op (the queue is implicitly initialized by all
relevant commands if needed), and queue repositories with -c are an
advanced usage of mq, and not otherwise required.
The goal of this patch is to add the IDs of the parents of applied MQ patches
into the patch file headers whenever qnew or qrefresh are run.
This will serve as a reminder of when the patches last applied cleanly and
will let us do more intelligent things in the future, such as:
* Resolve conflicts found when qpushing to a new location by merging
instead of simply showing rejects.
* Display better diffs of versioned MQ patches because we can tell how the
patched files have changed in the meantime.
Here are the new rules this patch introduces. They are checked in this order:
* If a patch currently has old, plain-style patch headers ("From:" and
"Date:") do not change the style or add any new headers.
* If the 'mq.plain' configuration setting is true, only plain-style
headers will be used for all MQ patches.
* qnew will initialize new patches with HG-style headers and fill in the
"# Parent" header with the appropriate parent node.
* qrefresh will refresh the "# Parent" header with the current parent of
the current patch.
The slow path/fast path distinction has existed since mq was added to Mercurial
in 2006. The slow path was used whenever the refreshed revision wasn't the tip
We should not translate the "imported patch" message. The translated message
confuses the detection whether the user has not updated the commit message yet.
We try to avoid to translate generated commit messages.
We need to do this to avoid file/directories conflicts.
This causes patches removing a committed file and replacing it
with a directory to be "unpoppable".
Since it only changes the working directory, it does not matter whether a patch is
applied. This change makes it easier to use hg import --no-commit instead of patch.
This fixes an incompatibility with patch(1), which also uses --reverse
for reversed diffs. The --inverse flag was added in 0f0383897d54. That
name was chosen over --reverse since it was thought that --reverse
would make --rev ambiguous.
It turns out that both flags can co-exist, with the cost that --rev
can no longer be shortened to --r and --re. Since one can always use
the short -r option, this is not a real problem.
After changeset 54b67f7bd5df, ui.username will abort by default if no
username is set. It is therefore wrong to call ui.username when a
username was provided on the command line.
Most of the time, one can reverse a diff by swapping the revisions passed with
-r but it happens that if you use the global -R, and diff against the tip of
the current repo, you can't swap the revisions. One use-case for that is
reviewing changes from a bundle before unbundling. One could also pipe the
output of `hg diff` to a command line filter that reverses the diff, but that
would remove the benefit from color diffs. Therefore, having an option in
`hg diff` to reverse a diff is a good thing.
The option flag selection was tricky. GNU patch uses -R/--reverse but -R is
already used as a global option and --reverse would make --rev ambiguous.
Normally, diffs without any text insertions or deletions are reported
as having 0 lines changed by stock diffstat. Compatibility is
preserved with stock diffstat in this case, but when using --git,
binary files are marked with Bin as a means of clarification.
git diff --stat does something similar, though it also includes the
old and new file sizes.
diff/qdiff --stat invokes patch.diffstat() on the diff output.
When in interactive mode, the output's maximum width is determined by the
terminal's width.
patch.extract extracts just the message below HG changeset patch. So to not
parse comments above the patch, we reset the message if we find a changeset
patch as we know the commit message comes after the changeset patch data.
This is similar to the behavior of patch.extract.
The drawback of this approach, after a qref -e the comment above HG changeset
patch is gone. Without this patch the message would become part of the commit
message in the HG changset patch part.
When setting the date with qrefresh (-d|-D), and the patch does have
neither a 'Date:' nor a '# Date' header, add the date field as such:
- if the patch has a 'From:' header, add a 'Date:' header
- otherwise, upgrade to Mercurial extended patch format and add '# Date'
When setting the author field with qrefresh (-u|-U), and the patch does have
neither a 'From:' nor a '# User' header, add the author name as such:
- if the patch has a 'Date:' header, add a 'From:' header
- otherwise, upgrade to Mercurial extended patch format and add # From
When navigating through a patch series by qpushing and qpopping it was easy to
get lost because qpop was silent. I found myself often running qnext after qpop
to see which patch I just dropped - especially if I was about to qrm it. This
patch makes qpop more symmetric to qpush by showing which patches are
applied/"unapplied".
I think it is a good change even though it changes output by adding a new line
of output.
The option will no longer show up in the list, unless --verbose is used.
'qdel -r' has been deprecated in favor of qfinish since the 1.1 release.
It is still fully functional, but new users need not learn about it.
Trying as much as possible to consistently:
- use a present tense predicate followed by a direct object
- verb referring directly to the functionality provided
(ie. not "add command that does this" but simple "do that")
- keep simple and to the point, leaving details for the long help
(width is tight, possibly even more so for translations)
Thanks to timeless, Martin Geisler, Rafael Villar Burke, Dan Villiom
Podlaski Christiansen and others for the helpful suggestions.
The built-in None object is a singleton and it is therefore safe to
compare memory addresses with is. It is also faster, how much depends
on the object being compared. For a simple type like str I get:
| s = "foo" | s = None
----------+-----------+----------
s == None | 0.25 usec | 0.21 usec
s is None | 0.17 usec | 0.17 usec
They are unnecessary. I did leave them in localrepo.py where there is
something like:
_junk = foo()
_junk = None
to free memory early. I don't know if just `foo()` will free the return
value as early.
This changes the behavior of qguard in the case of setting negative guards, as -- will now always be required.
Fixes issue1402.
Doc fixes for mq by mpm.
This extension produces quite a lot of informational messages during
its normal operation and it is hard to say which strings can be
changed and which cannot.
Copy information was saved in a common loop, then refined in a git-only block.
The problem was the latter did filter out renames occuring in the current
patch and irrelevant to commit. In the non-git case, copy records still existed
in the dirstate, referencing removed files, making the commit to fail. Git and
non-git copy handling paths are now separated for simplicity.
Reported by Gary Bernhardt
Changes docstrings to begin with a lowercase word. Only docstrings
used in help output is changed.
Scripts are not expected to grep the output of 'hg help' so this
change should pose no problem with regard to the compatibility rules.
pmezard expects
hg qref -s -X b
to apply the -X to the list of files in the patch, and thus remove b from the
patch.
That's how it worked before c302ef4372b2. That change seemed sensible, but it
wasn't...
mpm says
(17:22:30) pmezard_: kiilerix1: do you mean that -X should be forbidden with -s ?
(17:22:54) pmezard_: kiilerix1: and --include too
(17:23:03) mpm: No because you should be able to say hg qref -s foo* -X foo-bar
so mpm expects
hg qref -s -X b *
to apply the -X to the list of files in the working directory, and thus don't
include b in the patch
This patch tries to make both usecases work by creating a matchfn which uses
the include/excludes but not the filelist.
