GNU bug report logs - #73232
[PATCH] Allow vc-diff to suggest a default revision in vc-dir

Previous Next

Full log

Message #40 received at 73232-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 73232-done <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#73232: [PATCH] Allow vc-diff to suggest a default revision in
 vc-dir
Date: Thu, 10 Oct 2024 02:36:54 +0300

On 04/10/2024 14:38, Spencer Baugh wrote:
>>> Here's what seems to me an overall improvement, based on the
>>> original change. And more consistent as well.
>>> * No special case for when FIRST is a directory OR it's not
>>> up-to-date.
>>> * Make REV1-DEFAULT a list value.
>>> * In 'vc-root-version-diff', don't try calling 'vc-deduce-fileset'
>>> and construct a (BACKEND DEFAULT-DIR) fileset right away.
>>> As a result, 'C-u C-x v d' consistently provides completion and diff
>>> relating to the whole repository, not for files as point (if
>>> any). Previously, it used the revision that last touched the
>>> corresponding file, or nil, if the file was untracked (e.g. in
>>> Dired).
>>> Further, don't offer the working revision as REV1-DEFAULT. Except
>>> for historical reasons and some idea of consistency, I can't see a
>>> scenario where that would be useful, which would not be covered by
>>> calling 'C-x v d' without a prefix. Someone please correct me here.
>>> And combined with Spencer's patch from
>>> https://debbugs.gnu.org/62940#46, we get this:
>>> * First default is HEAD^ (the last revision before the latest).
>>> * Second default is @{upstream}.
>>> * Then the elements from vc-revision-history.
>>> WDYT?
> This seems reasonable to me.  Then we have the following reliable
> behaviors:
> 
> - [some diff command] RET
>     diffs the working tree against HEAD
> - C-u [some diff command] RET RET
>     diffs the working tree against HEAD^
> - C-u [some diff command] M-n RET RET
>     diffs the working tree against @{upstream}
> 
> This seems like a big improvement, since previously would need to
> actually read the prompt in the C-u case to figure out whether the
> default was correct/what you wanted.

Yep, I think predictability is key.

Since there seem to be no objections, I've pushed the proposed change to 
master (just step number 2, the 3rd one is in another bug#). If 
anybody's having problems as a result, feedback welcome.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.