Before this patch, hg record was running hg commit -i, therefore with the
experimental.crecord=True flag, hg record was actually launching the curses
record interface. Some of our users could be confused by that.
This patch makes the hg record command set this flag to False, ensuring that
hg record never shows the curses interface.
commit -i, shelve -i and revert -i remain unchanged and use the curses
interface if the experimental.crecord flag is set.
Extension authors (notably at companies using hg) have been
cargo-culting the `testedwith = 'internal'` bit from hg's own
extensions, which then defeats our "file bugs over here" logic in
dispatch. Let's be more aggressive about trying to give extension
authors a hint about what testedwith should say.
Rev cb4d72125aae adding a parameter here. This breaks third-party extensions
like crecord and also makes the issue fairly hard to fix on the extension's
side if it wants to retain compatibility across Mercurial versions -- in old
versions, the positional argument will be passed into the next unknown
argument, which is 'files'.
The patch also undoes a change to the record extension that is no longer
necessary.
While using the record extension to select changes, the user couldn't see the
content of newly added files and had to select/reject them based on filename.
The test is changed accordingly in two places.
Commit 9bcdffd81aaf changed how newfiles get passed to commitfunc, but
did not change the corresponding comment that explains this. This
commit also updates this comment.
Record was changing the current directory to `repo.root` in order to be able to
feed `command.commit` file name relative to this `repo.root`. This is a bit
overkill and prevent an incoming fix to rebase. This would also break
multi-threaded usage.
Instead we just feed `command.commit` with absolute path name. works as well as
before but without chdir.
It looks like somewhere down the line, patch.diffopts changed the
names of the options that it recognises, but record.recordfunc wasn't
updated to the new names. Instead of trying to write down names at
all, we now use whatever names are provided in commands.diffwsopts and
pass that along to patch.diffopts, along with a couple of custom
options
The record extension is writing its own version of commands.diffwsopts
which is identical to commands.diffwsopts. Based on the principle that
code duplication increases maintenance burden, this patch removes
record's ad-hoc diffopts in favour of commands.diffwsopts
Before this patch, record extension gets the list of available
responses from online help document of "hg record" in the tricky way,
even though the value passed to "ui.promptchoice()" has enough (maybe
i18n-ed) information.
This patch uses "ui.extractchoices()" to get the list of available
responses.
The -u flag didn't work when ui.username was not set and resulted in an
abort message. This was fixed by checking for the 'user' key in the opts
dictionary. If the key is present, the step causing the exception is not
executed.
This makes record work more like import which ignores for instance mail footers
in a patch file.
This also makes it possible for TortoiseHg to preview unapplied patches
containing such footers.
Maintain a whitelist of commands to infer the repo for instead. The whitelist
contains those commands that take file(s) in the working dir as arguments.
46cdcb89086f fixed display of non-ASCII names in file-selecting prompt, but
display in chunk selection remained broken. The reason is that using '%r' in
string formatting results in calling `repr` on file names, thus mangling
non-ASCII ones.
It is possible that unrelated changes in a file are on sequential lines. The
current record extension does not allow these to be committed independently.
An example use case for this is in software development for deeply embedded
real-time systems. In these environments, it is not always possible to use a
debugger (due to time-constraints) and hence inline UART-based printing is
often used. When fixing a bug in a module, it is often convenient to add a
large number of 'printf's (linked to the UART via a custom fputc) to the module
in order to work out what is going wrong. printf is a very slow function (and
also variadic so somewhat frowned upon by the MISRA standard) and hence it is
highly undesirable to commit these lines to the repository. If only a partial
fix is implemented, however, it is desirable to commit the fix without deleting
all of the printf lines. This is also simplifies removal of the printf lines
as once the final fix is committed, 'hg revert' does the rest. It is likely
that the printf lines will be very near the actual fix, so being able to split
the hunk is very useful in this case.
There were two alternatives I considered for the user interface. One was to
manually edit the patch, the other to allow a hunk to be split into individual
lines for consideration. The latter option would require a significant
refactor of the record module and is less flexible. While the former is
potentially more complicated to use, this is a feature that is likely to only
be used in certain exceptional cases (such as the use case proposed above) and
hence I felt that the complexity would not be a considerable issue.
I've also written a follow-up patch that refactors the 'prompt' code to base
everything on the choices variable. This tidies up and clarifies the code a
bit (removes constructs like 'if ret == 7' and removes the 'e' option from the
file scope options as it's not relevant there. It's not really a necessity, so
I've excluded it from this submission for now, but I can send it separately if
there's a desire and it's on bitbucket (see below) in the meantime.
Possible future improvements include:
* Tidying up the 'prompt' code to base everything on the choices variable.
This would allow entries to be removed from the prompt as currently 'e' is
offered even for entire file patches, which is currently unsupported.
* Allowing the entire file (or even multi-file) patch to be edited manually:
this would require quite a large refactor without much benefit, so I decided
to exclude it from the initial submission.
* Allow the option to retry if a patch fails to apply (this is what Git does).
This would require quite a bit of refactoring given the current 'hg record'
implementation, so it's debatable whether it's worth it.
Output is similar to existing record user interface except that an additional
option ('e') exists to allow manual editing of the patch. This opens the
user's configured editor with the patch. A comment is added to the bottom of
the patch explaining what to do (based on Git's one).
A large proportion of the changeset is test-case changes to update the options
reported by record (Ynesfdaq? instead of Ynsfdaq?). Functional changes are in
record.py and there are some new test cases in test-record.t.
