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.
