[Top][All Lists]

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

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

From: Dmitry Gutov
Subject: bug#34949: 27.0.50; Docstring of `vc-deduce-fileset' incomplete
Date: Tue, 25 Feb 2020 12:32:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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:

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.

reply via email to

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