Embedded passwords are masked only in plain output because we'll want raw
values in machine-readable format such as JSON. For custom template, we can
add a filter to mask passwords (e.g. "{url|hidepassword}").
path.rawloc field is called as "url" than "path" because we have "pushurl"
sub-option. Also, "name" and "url" are not allowed as sub-options as they
conflict with the field names.
Truth table (extracted from the original implementation):
search quiet name path subopt
------ ----- ---- ---- ------
f f T T T
f T T f f
T f f T f
T T f f f
This prepares for porting to the formatter API. Future patches will use a
single loop to handle both search=None|pattern cases because formatter output
should be the same. "pathitems" will be switched instead.
This aligns with the unconditional plural output for the update line contents,
as well as the incoming/outgoing bookmarks line. It also matches the message
in evolve's summary hook as of 4f83b2d2d20d. (Though I thought this was removed
recently?)
This patch adds a capability to hg debugignore: to explain why a given file is
being ignores by mercurial. We display the filename, line and linenumber of the
rule that lead us to ignore the file.
Before this patch debugignore was just displaying the list of ignore patterns.
This patch makes it support a list of filename as argument and tells the user
if those given files are ignored or not.
The bookmark/checkout help actually split the pull help.
The subsequent verbose container is talking about pull too.
This change puts the pull help back together again.
Expose afterresolvedstates to allow graft and similar to
suggest a message when resolving results in no unresolved
files.
If there isn't a matching state in afterresolvedstates,
then if verbose, suggest commiting.
Implementing `hg parents -r REV FILE` correctly is hard.
The output can be 0, 1, or 2 revs.
First, you can't use parents(), because it sorts its output...
Consider:
echo $a
echo par@rev: `hg log -r "parents($a)" -q`
echo p12@rev: `hg log -r "p1($a)+p2($a)" -q`
echo parents: `hg parents -q -r $a`
(Merge 1 into 0)
3
par@rev: 0:d9612eafe8ec 1:070fe4290d06
p12@rev: 0:d9612eafe8ec 1:070fe4290d06
parents: 0:d9612eafe8ec 1:070fe4290d06
(Merge 4 into 5)
6
par@rev: 4:db73392995c3 5:c26e7dd67644
p12@rev: 5:c26e7dd67644 4:db73392995c3
parents: 5:c26e7dd67644 4:db73392995c3
(Merge 7 into 8)
9
par@rev: 7:d84f47462f70 8:9597bcab36e0
p12@rev: 8:9597bcab36e0 7:d84f47462f70
parents: 8:9597bcab36e0 7:d84f47462f70
You also can't use parents or/p1/p2 alone with a set, as in:
-r "parents(::REV and file(FILE))"
-r "parents(::REV - REV and file(FILE))"
... because each will return all parents for each candidate revision,
and the :: gives too many candidates.
Thus, we need a max and a p1/p2.
Also, anything of this form:
max(::REV - REV and file(FILE))
... is wrong, because max will return only one revision, and for
a proper parents, you need to return two occasionally.
Lastly, it doesn't help that `hg parents -r REV FILE` is buggy
due to a quirk in filelogs.
Here's a repository to consider when evaluating whether your
revset is correct:
$ hg log -G --template '{rev} {files}\n';
@ 10 a
|
o 9 a b
|\
| o 8 a
| |
o | 7 a
| |
+---o 6 b
| |/
| o 5 b
| |
o | 4 b
| |
+---o 3
| |/
+---o 2
| |/
| o 1 b
|
o 0 a
revs 4 and 5 create a conflict.
The conflict is resolved in the same way by both 6 and 9.
You would hope that parents around 9/10 would point to 9,
but `hg parents` will point to 6 due to the aforementioned bug.
Here's the winning solution test script and its output.
echo $a;
echo rp12-max: `hg log -r "max(::p1($a) and file(b)) + max(::p2($a) and file(b))" -q` 2> /dev/null;
echo expected: `hg parents -q -r $a b` 2> /dev/null;
Note that for 10, the output differs, but again, this is because
of the aforementioned bug. The rp12-max output is "correct",
whereas "expected" is just an unfortunate bug. The abort output
is due to something else. I'm not sure why someone thought it
was important to abort to stdio instead of stderr, but that's
really not my problem here.
10
rp12-max: 9:184ebefc2fce
expected: 6:dd558142b03f
9
rp12-max: 5:c26e7dd67644 4:db73392995c3
expected: 5:c26e7dd67644 4:db73392995c3
8
rp12-max: 5:c26e7dd67644
expected: 5:c26e7dd67644
7
rp12-max: 4:db73392995c3
expected: 4:db73392995c3
6
rp12-max: 5:c26e7dd67644 4:db73392995c3
expected: 5:c26e7dd67644 4:db73392995c3
5
rp12-max: 1:070fe4290d06
expected: 1:070fe4290d06
4
rp12-max:
abort: 'b' not found in manifest!
expected:
3
rp12-max: 1:070fe4290d06
expected: 1:070fe4290d06
2
rp12-max: 1:070fe4290d06
expected: 1:070fe4290d06
1
rp12-max:
abort: 'b' not found in manifest!
expected:
0
rp12-max:
abort: 'b' not found in manifest!
expected:
We have a nice API now. Use it.
This does mean we introduce an extra index lookup for each revision.
Considering this is a debug command, the overhead should be acceptable.
We could add the chain size to revlog._deltachain(). However, that
feels like avoidable overhead.
Now that we have multiple directories where help topics can live,
we need a mechanism to access them. We already use "." to
separate topic from section. So it seems logical to also use "." to
denote the sub-directory of a topic.
This patch teaches the help command to parse out the possible
sub-topic and pass it to the help system.
We generally make modules importable from the front-end layer, dispatch ->
commands -> x. So the import cycle to dispatch should be resolved by the
commandserver module.
Since 3be994f0f015, #fragment was missing in "hg paths" output because
path.loc was changed to a parsed URL. "hg paths" should use path.rawloc to
show complete URLs.
Previously, we'd restore the .orig file after the premerge is complete but
before the merge was complete. This would lead to the .orig file potentially
containing merge conflict markers in it, as a leftover from the last merge
attempt.
