[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merge-base alias for git vc-diff

From: João Távora
Subject: Re: Merge-base alias for git vc-diff
Date: Thu, 03 Jan 2019 21:44:05 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Juri Linkov <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]