Johannes Schindelin [off-list ref] writes:
quoted
quoted
+- `<rev1>...<rev2>`. This resembles the symmetric ranges mentioned in
+ the `SPECIFYING RANGES` section of linkgit:gitrevisions[7], and is
+ equivalent to `<base>..<rev1> <base>..<rev2>` where `<base>` is the
+ merge base as obtained via `git merge-base <rev1> <rev2>`.
The above paragraph says A...B is turned into $(git merge-base A
B)..A and $(git merge-base A B)..B, but I wonder if we should be
rewriting it into A..B and B..A instead; that would make it
unnecessary to explain what should happen when there are more than
one merge bases.
quoted
Does this merely resemble? Isn't it exactly what a symmetric range is?
No, it is not exactly what a symmetric range is because `range-diff`
treats both arms of the symmetric range independently, as two distinct
non-symmetric ranges.
This however is an end-user documentation, isn't it?
The fact that range-diff internally translates A...B into something
else is an implementation detail of achieving something, and from
the end-users' point of view, isn't it "take A...B from the
end-user, and show the difference between the left and right
branches of the symmetric range" that range-diff achieves to do?
So it processes exactly the same two sets of commits as what is
given by "--left-right A...B", no?
Hi Junio,
On Fri, 22 Jan 2021, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
quoted
quoted
+- `<rev1>...<rev2>`. This resembles the symmetric ranges mentioned in
+ the `SPECIFYING RANGES` section of linkgit:gitrevisions[7], and is
+ equivalent to `<base>..<rev1> <base>..<rev2>` where `<base>` is the
+ merge base as obtained via `git merge-base <rev1> <rev2>`.
The above paragraph says A...B is turned into $(git merge-base A
B)..A and $(git merge-base A B)..B, but I wonder if we should be
rewriting it into A..B and B..A instead; that would make it
unnecessary to explain what should happen when there are more than
one merge bases.
You know what? I lied. The code already does what you suggested. Look
[here](https://github.com/git/git/blob/v2.30.0/builtin/range-diff.c#L59-L77):
[...]
} else if (argc == 1) {
const char *b = strstr(argv[0], "..."), *a = argv[0];
int a_len;
if (!b) {
error(_("single arg format must be symmetric range"));
usage_with_options(builtin_range_diff_usage, options);
}
a_len = (int)(b - a);
if (!a_len) {
a = "HEAD";
a_len = strlen(a);
}
b += 3;
if (!*b)
b = "HEAD";
strbuf_addf(&range1, "%s..%.*s", b, a_len, a);
strbuf_addf(&range2, "%.*s..%s", a_len, a, b);
[...]
quoted
quoted
Does this merely resemble? Isn't it exactly what a symmetric range is?
No, it is not exactly what a symmetric range is because `range-diff`
treats both arms of the symmetric range independently, as two distinct
non-symmetric ranges.
This however is an end-user documentation, isn't it?
Yes, and the end user is talking about _two_ commit ranges in the context
of `git range-diff`, and about _one_ commit range in the context of `git
log`.
So I still think that it really just only resembles the symmetric range.
It is fundamentally as different from it as the number 2 is different from
the number 1.
Ciao,
Dscho