Re: Merge-base alias for git vc-diff

["João Távora" <joaotavora@gmail.com>]

Juri Linkov <juri@linkov.net> writes:

>> 2. A diff is always a comparison of two revisions, right?  For vc-dir,
>>    isn't a UI like query-replace's suitable here?  You know, that thing
>>    where you type the pattern and the replacement interactively in the
>>    same minibuffer prompt, separated by the arrow.  You can M-p, C-r,
>>    etc, flawlessly. I really like that UI, it's really intuitive (kudos
>>    to whoever participated, btw).
>>
>>    So here, instead of pattern and replacement, two revisions.  All one
>>    would need, apparently, is to turn the arrow into a ".." and make it
>>    toggleable to "..." with say, C-M-y.  I think it would simplify the
>>    completion problem: on both sides of the ".." or "..." you just
>>    complete a revision using whatever system we presumably already have
>>    in place for that.
>
> Good idea.

Cool. I'd say go for it! (unless someone seriously objects).

For a first stab at this, most of the UI work would be in
vc-diff-build-argument-list-internal which would, if passed an optional
argument, say CHOOSE-REVISION-RELATIONSHIP, use the new UI and return an
extra element at the end saying the merge-base should be used.  It
should be a question of grabbing this element in vc-version-diff and
passing it this down to vc-<backend>-diff.

The Git backend would know how to handle it (as could presumably other
backends).  The value of CHOOSE-REVISION-RELATIONSHIP passed in
vc-version-diff could be a backend-specific decision.

> The only problem is that then we have to use different amount of dots
> for vc-root-diff and vc-print-root-log because in git: ‘git diff
> A...B’ corresponds to ‘git log A..B’ whereas ‘git diff A..B’
> corresponds to ‘git log A...B’

Really? Ugh, that unfortunate.  Well we could just live with it or use
different symbols to abstract it away.

João