- Oct 02, 2011
-
-
Greg Ward authored
The old code printed (with ui.status()) the changeset ID created by patch N after committing patch N+1, e.g. applying patch1 applying patch2 applied 1d4bd90af0e4 where 1d4bd90af0e4 is the changeset ID resulting from patch1. That's just weird. It's also inconsistent: we only reported the changeset ID when applying >1 patches. And it's inconsistent with 'commit', which only tells you the new changeset ID in verbose mode. Finally, the existing code was I18N-hostile, since it concatenated translated strings. The new way is to print the just-created changeset ID with ui.note() immediately after committing it. It also clarifies what the user message is for easier I18N.
-
- Oct 07, 2011
-
-
Matt Mackall authored
This was causing test-convert-cvs.t to fail.
-
- Oct 02, 2011
-
-
Matt Mackall authored
This fixes option lists for commands with only an --mq option.
-
Matt Mackall authored
subprocess was returning the following unhelpful message: abort: No such file or directory
-
- Oct 01, 2011
-
-
Matt Mackall authored
-
Greg Ward authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Greg Ward authored
You can get into trouble if you commit, update back to an older changeset, and then rollback. The update removes your valuable changes from the working dir, then rollback removes them history. Oops: you've just irretrievably lost data running nothing but core Mercurial commands. (More subtly: rollback from a shared clone that was already at an older changeset -- no update required, just rollback from the wrong directory.) The fix assumes that only "commit" transactions have irreplaceable data, and allows rolling back non-commit transactions as always. But when rolling back a commit, check that the working dir is checked out to tip, i.e. the changeset we're about to destroy. If not, abort. You can get back the old (dangerous) behaviour with --force.
-
- Sep 30, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Sep 26, 2011
-
-
Katsunori FUJIWARA authored
-
- Sep 30, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
- Sep 29, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
Matt Mackall authored
-
- Sep 24, 2011
-
-
various authored
This code has a number of contributors and a complicated history prior to its introduction that can be seen by visiting: https://developers.kilnhg.com/Repo/Kiln/largefiles/largefiles http://hg.gerg.ca/hg-bfiles and looking at the included copyright notices and contributors list.
-
- Sep 28, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
There are no longer any prompts that insist on being answered, so the loop is no longer needed, nor is most of the other logic.
-
- Sep 08, 2010
-
-
Matt Mackall authored
This matches our pre-existing behavior from: changeset: 12197:540693065d40 user: Christian Ebert <blacktrash@gmx.net> files: hgext/patchbomb.py tests/test-patchbomb.t description: patchbomb: show prompt and selection in non-interactive mode changeset: 8940:01ada7b1861d user: Mads Kiilerich <mads@kiilerich.com> date: Sun Jun 21 03:13:38 2009 +0200 files: mercurial/ui.py tests/test-merge-prompt.out tests/test-merge-tools.out description: ui.prompt: Show prompt and selection in non-interactive mode
-
- Sep 28, 2011
-
-
Greg Ward authored
- prompt(): respect interactive mode; clarify logic a bit - rename introneeded() to introwanted() and give it only one caller - add 'numbered' arg to makepatch() so it does not need to call introwanted() - factor makeintro() out of getpatchmsgs(), so it's easier to skip the intro message based on the user's behaviour Unexpected but perfectly reasonable side effect: in non-interactive mode, we don't show unanswerable "Cc" or "From" prompts anymore, so remove those from the test expectations.
-
- Sep 20, 2011
-
-
Nikolaj Sjujskij authored
If Python interpreter was built under Linux 3.x kernel, it reports sys.platform to be 'linux3' (it is fixed for Python 3, but not for 2.x). This cancels building inotify extension, which was built only for 'linux2' platform. Improved test checks if sys.platform begins with 'linux', and together with test for kernel version to be greater than 2.6 it seems to cover all known cases.
-
- Sep 27, 2011
-
-
Greg Ward authored
-
- Sep 28, 2011
-
-
Matt Mackall authored
-
- Sep 27, 2011
-
-
kiilerix authored
It is apparently possible to compile Python without SSL support or leave it out when installing precompiled binaries. Mercurial on such Pythons would crash if the user tried to use https. Now it will be reported as "abort: Python SSL support not found" instead.
-
Matt Mackall authored
-
Steffen Daode Nurpmeso authored
The line content of continued Subject: lines was yet joined via str.replace('\n\t', ' '), which does not handle continuation via spaces. So expan the regular expression instead to handle all allowed forms of mail header line continuation.
-
- Sep 23, 2011
-
-
Kevin Gessner authored
Post-2038 timestamps cannot be handled on 32-bit architectures. Clamp such dates to the maximum 32-bit timestamp.
-
- Sep 21, 2011
-
-
Yann E. MORIN authored
The style is based on the 'default' style, but adds the bisection status of the changesets. Example output for a changeset in range: $ hg log --style bisect -r 15:16 changeset: 15:857b178a7cf3 bisect: bad parent: 13:b0a32c86eb31 parent: 10:429fcd26f52d user: test date: Thu Jan 01 00:00:15 1970 +0000 summary: merge 10,13 changeset: 16:609d82a7ebae bisect: bad (implicit) user: test date: Thu Jan 01 00:00:16 1970 +0000 summary: 16 $ hg log --quiet --style bisect 18:d42e18c7bc9b B 17:228c06deef46 B 16:609d82a7ebae B 15:857b178a7cf3 14:faa450606157 G 13:b0a32c86eb31 G 12:9f259202bbe7 G 11:82ca6f06eccd U 10:429fcd26f52d S 9:3c77083deb4a G 8:dab8161ac8fc 7:50c76098bbf2 I 6:a214d5d3811a I 5:385a529b6670 I 4:5c668c22234f I 3:0950834f0a9c I 2:051e12f87bf1 1:4ca5088da217 0:33b1f9bc8bc5 Signed-off-by:
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
-
Yann E. MORIN authored
This new 'bisect' template expands to a cset's bisection status (good, bad and so on...). There is also a new 'shortbisect' filter that yields a single char representing the cset's bisection status. It uses the two recently-added hbisect.label() and .shortlabel() functions. Example output using the repository in test-bisect2.t, and some made-up state of the 'end at merge' test (with graphlog, it's so explicit): $ hg glog --template '{rev}:{node|short} {bisect}\n' \ -r 'bisect(range)|bisect(ignored)' o 17:228c06deef46: bad | o 16:609d82a7ebae: bad (implicit) | o 15:857b178a7cf3: bad |\ | o 13:b0a32c86eb31: good | | | o 12:9f259202bbe7: good (implicit) | | | o 11:82ca6f06eccd: good | | @ | 10:429fcd26f52d: untested |\ \ | o | 9:3c77083deb4a: skipped | |/ | o 8:dab8161ac8fc: good | | o | 6:a214d5d3811a: ignored |\ \ | o | 5:385a529b6670: ignored | | | o | | 4:5c668c22234f: ignored | | | o | | 3:0950834f0a9c: ignored |/ / o / 2:051e12f87bf1: ignored |/ And now the same with the short label: $ hg log --template '{bisect|shortbisect} {rev}:{node|short}\n' 18:d42e18c7bc9b B 17:228c06deef46 B 16:609d82a7ebae B 15:857b178a7cf3 14:faa450606157 G 13:b0a32c86eb31 G 12:9f259202bbe7 G 11:82ca6f06eccd U 10:429fcd26f52d S 9:3c77083deb4a G 8:dab8161ac8fc 7:50c76098bbf2 I 6:a214d5d3811a I 5:385a529b6670 I 4:5c668c22234f I 3:0950834f0a9c I 2:051e12f87bf1 1:4ca5088da217 0:33b1f9bc8bc5 Signed-off-by:
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
-
- Sep 22, 2011
-
-
Yann E. MORIN authored
Add two new functions that return a string containing the bisection status of the node passed in parameter: - .label(node): return a multi-char string representing the status of node - .shortlabel(node): return a single-char string representing the status of node, usually the initial of the label bisection status .label() .shortlabel() ---------------------------------------------------------- good 'good' 'G' good (implicit) 'good (implicit)' 'G' bad 'bad' 'B' bad (implicit) 'bad (implicit)' 'B' skipped 'skip' 'S' untested 'untested' 'U' ignored 'ignored' 'I' (others) None None There is no point in returning 'range' or 'pruned', as these get covered by another, more meaningful status in the table above. In case the node is not being bisected, the functions return None to leave it up to the caller to decide what to print (nothing, an empty space, or whatever else suits). Signed-off-by:
"Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
-