Ramkumar Ramachandra <artag...@gmail.com> writes:
> What are your thoughts on inventing a new syntax A~B = $(git
> merge-base A B) B which can be used by both range commands like log
> and non-range commands like diff ? (In other words, why shouldn't log
> be able to do this?).
The idea for a new syntax to denote a merge base may be an
"log" is inherently about ranges, so you do not need a new operator
to denote a merge base. Between "log A..B" and "log A...B" with or
without --left-right, --left-only and --right-only, you should be
able to ask questions about histories leading to commit A and B
without having to worry about a single "merge base" between A and B,
no? So I do not think "A~B" would help "log".
Because "diff" is inherently about endpoints, you DO have to have a
single "merge base" that gives you a point to compare something else
The reason why "diff A...B" was invented was primarily because we
wanted to avoid having to say A twice on the command line, be it
"diff $(git merge-base A B) B" or "diff A~B B". In other words,
"A~B" will not help "diff" at all, either [*1*].
There isn't always a single merge base between an arbitrary pair of
commits (there may be 0, or 2 or more). When used in the context of
"diff A...B", we know that the user is more interested in using one
merge base (among possibly many) to get some diff, than seeing the
command fail [*2*]. Taking that as a context cue, "diff A...B" can
(and did) choose to use one picked at random, even though the design
is fully aware that the chosen one may not be the best one.
A generic "A~B" syntax implemented at the revision parser level may
not have that luxury of assuming that it is fine to pick any, and
may have to fail when there is not a unique merge-base.
*1* That does not mean nobody needs that syntax. It just means that
it is still a solution looking for a problem.
*2* Otherwise the user can more carefully script what he wants to do
using the merge-base command himself, choosing to do different
things when there are 0, or 2 or more merge bases.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html