Subject: bug#34949: 27.0.50; Docstring of `vc-deduce-fileset' incomplete

From: Dmitry Gutov <[email-masked]>
Date: Tue, 25 Feb 2020 12:32:25 +0200

On 25.02.2020 2:12, Juri Linkov wrote:
>>>> Um, not really. Just only adding the 'V' binding to VC-Dir buffers, where
>>>> it would use the existing known fileset. But no 'C-x v V' binding.
>>> Should then 'V' typed in VC-Dir operate on edited files only,
>>> or try to use all files including unregistered?
>>
>> Which option would you choose?
> 
> The most often used operation is to commit edited files.

Probably, yes. Considering people like to leave some unregistered files 
out indefinitely.

>> Do you know why we generally try to only operate on the files in the
>> same status?
> 
> Maybe to make it easier to e.g. register all unregistered files:
> in VC-Dir type 'm' on an unregistered file that will mark all
> unregistered files, then register them with 'v'.

Thinking about that, I believe it's because the thing that 
vc-next-action does depends on the status of the files in the fileset. 
So the statuses have to be compatible.

>>>> If that would both satisfy you and simplify the implementation, of course.
>>> What about invoking state-changing VC-operations from Dired?
>>> Should typing 'v' in Dired open the VC-Dir buffer?
>>
>> No, I just wouldn't do that.
> 
> Then typing 'v' in Dired should open the *vc-log* buffer
> for writing a commit message on all edited files,
> ignoring all unregistered files?

Yes, OK.

>>> BTW, why 'C-x v d RET' requires a confirmation?
>>> This additional 'RET' is too annoying.
>>
>> You participated in this discussion:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12492
>>
>> Since then, we've had at least another one on the same subject. The
>> consensus was the current behavior. If you can find that discussion,
>> please go ahead and revive it if you like. Not in this bug report, though.
> 
> I remember bug#12492, but not any other discussion.

Commit f302475471df0553b3ee442112981f9b146e0b55 came later. You can try 
searching for the thread (probably on emacs-devel) that led to it.