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.
Also, don't create a backup dir if we have no files to backup.
This is essential for qrefresh --interactive. Since we can't
select individual files to qrefresh without eliminating already
present changes, we have to backup all changes in the working
copy to avoid refreshing unaccepted hunks.
(thanks to Patrick for the idea)
_updatedir() is no longer used by internalpatch()
The change in test-mq-missingfiles.t comes from workingbackend not considering
the missing 'b' file as changed, thus not calling addremove() on it.
This turns the prompt sequence from something like:
$ examine changes to foo?
$ record change 1/4 to foo?
$ record change 2/4 to foo?
$ examine changes to bar?
$ record change 4/4 to bar?
into:
$ examine changes to foo?
$ record change 1/3 to foo?
$ record change 2/3 to foo?
$ examine change to bar?
$ record change 3/3 to bar?
The previous loop was iterating over a mixed header/hunk stream. It may have
been more generic in the sense every item in the stream could trigger a prompt
but it required more work to skip items properly. It can be rewritten in a more
intuitive way by looping on files then looping on hunks.
The --force option to qnew has become a no-op, so qrecord doesn't need
to use it. This allows record's command table to be simplified; in the
process of doing so, this patch also cleans up the cmdtable visually.
These changes are not useful to record itself, since it is hard coded
to always generate git style diffs. But it makes parsepatch() more
generally useful for parsing normal patch files.
226847bf9cab updated copyfile to also copy over atimes and
mtimes. That behavior is specifically to trick editors into thinking
files that hg record has modified haven't changed. We don't really
care about preserving times in the general case.
per "record" hunk
Record deals in hunks which are tighter than traditional patch hunks,
really only a single run of additions/removals. Another addition, even a
line after a fixed line is treated as a new hunk by record.
Py3k has removed the dictionary has_key method. This patch implements
a one argument function that can be used as a callback by hg.revert in
the record extension.
Quoting python's documentation, "Note that sum(range(n), m) is
equivalent to reduce(operator.add, range(n), m)". The "sum" function
is a builtin from 2.3 on and there's no reason for not to use it.
It might sound like a good idea to use record to filter changes when merging.
If someone attemps this, it's better to tell her "no" right ahead, before the
patch generation/line selection, so she does not spend time doing it just to
receive a red light after that (sometimes rather long) process.
The prompt function would return 'y' or 'n' untranslated. This should
therefore not be compared to _('y') and _('n'). However, it turns out
that prompt could just as well return a good old Boolean.
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.
Use ampersands (&) to delineate the response char in each choice.
ui.prompt() responses are now explicitly case insensitive. GUIs
that subclass ui can generate dialogs from the full choice names.
The old code would confuse the user if the translator actually
translated the letters "Ynsfdaq?" in the prompt, since the user input
would be matched against the English string, despite the translation.
The new code fixes this, but the translator must be 100% consistent.
Also, the translation of single character strings is problematic if
they are used differently by different pieces of code.
The record extension incorrectly re-calculated the size lines for unified
diff hunks. It counted a '\\ No newline at end of file\n' line towards the
number of lines of trailing context, while it's not actually part of the
context (and certainly isn't added as a line to the resulting output).
Use the local name of a variable that was access through the nonlocal scope
while we're at it. Seeing the variable was a little bewildering.
Also there is an idea flying around to create something that will complement
qrefresh:
- maybe 'qammend'? or
- 'qrefresh --interactive'?
If we settle on '--interactive', then it would be conveniet to add this flag to
'commit' and 'qnew' as well.
I'm a former Darcs user, and I've discovered that it is very convenient to
actually perform development using MQ first, and only when the patches are
'ready' move them to project's history in stone.
Usually I work on some topic, temporarily forgetting about any version control,
and just do coding, experimenting, debugging, etc.
After some time, I approach a moment, where my work should actually go to
patches/commits, and here is the problem::
As it is now, there is no way to put part of the changes into one patch,
and another part of the changes into second patch.
This works, but only when changes are touching separate files, and for
semantically different changes touching the same file(s) there is now
pretty way to put them into separate patches.
For some time, I've tolerated the pain to run vim patches/... and move hunks
between files by hand, but I think this affects my productivity badly.
So, here is the first step towards untiing the problem:
Let's use 'hg qrecord' for mq, like we use 'hg record' for usual commits!
rationale
---------
I'd like to make MQ version of record -- qrecord.
>From the first glance it seemed to be easy -- the task in essence would be to
change call to cmdutil.commit() to something like mq.qrefresh().
As it turned out queue.refresh() and cmdutil.commit() have different semantics
-- cmdutil.commit() first scans for changes and then delegate the actual commit
to lowlevel func. On the other hand queue.refresh() do it all in once, and I am
a bit scary to change it.
Maybe the right way would be to first refactor queue.refresh() to use
cmdutil.commit() machinery, and then trivially adjust record, but I feel I'm
not competent for the task right now.
Instead, I propose we refactor record to be some sort of high-level driver, or
like a high-level decorator one can say, which will first interactively filter
changes, and then delegate commit job to high-level commiter, e.g. 'commit' or
'qrefresh'
So, this patch does just that -- refactor record to be generic driver, and
update 'hg record' code to use the driver.
'hg qrecord' will follow.
Python already lets one to embed RE flags directly in a regex, which
is a much nicer way to do things:
(?iLmsux)
(One or more letters from the set "i", "L", "m", "s", "u", "x".)
...
matchflags was introduced in 14a7e862c60f, and the record extension is the only
user. I've killed matchflag, and adjusted record code appropriately.
