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"
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.
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.
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.
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.
