* bug#37223: 26.2; vc does not honor backup-directory-alist
@ 2019-08-29 19:55 ndame
2019-09-14 0:40 ` Dmitry Gutov
0 siblings, 1 reply; 5+ messages in thread
From: ndame @ 2019-08-29 19:55 UTC (permalink / raw)
To: 37223
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
I often use vc log and then f (log-view-find-revision) to view a
specific revision of a file.
The problem is the file is checked out to the same directory as the
original file with a backup file name (~, polluting the directory with
such files if multiple versions are perused.
These are backup files, the vc function uses that name too
(vc-version-backup-file-name), so their placements should honor
backup-directory-alist which is currently ignored.
[-- Attachment #2: Type: text/html, Size: 507 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#37223: 26.2; vc does not honor backup-directory-alist
2019-08-29 19:55 bug#37223: 26.2; vc does not honor backup-directory-alist ndame
@ 2019-09-14 0:40 ` Dmitry Gutov
2019-09-14 19:20 ` ndame
0 siblings, 1 reply; 5+ messages in thread
From: Dmitry Gutov @ 2019-09-14 0:40 UTC (permalink / raw)
To: ndame, 37223
On 29.08.2019 22:55, ndame wrote:
> I often use vc log and then f (log-view-find-revision) to view a
> specific revision of a file.
>
> The problem is the file is checked out to the same directory as the
> original file with a backup file name (~, polluting the directory with
> such files if multiple versions are perused.
>
> These are backup files, the vc function uses that name too
> (vc-version-backup-file-name), so their placements should honor
> backup-directory-alist which is currently ignored.
I don't know if they should. The current behavior is a long-standing one.
But more opinions are welcome.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#37223: 26.2; vc does not honor backup-directory-alist
2019-09-14 0:40 ` Dmitry Gutov
@ 2019-09-14 19:20 ` ndame
2019-09-19 20:22 ` Juri Linkov
0 siblings, 1 reply; 5+ messages in thread
From: ndame @ 2019-09-14 19:20 UTC (permalink / raw)
To: 37223@debbugs.gnu.org, Dmitry Gutov
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
>
> >
> > These are backup files, the vc function uses that name too
> > (vc-version-backup-file-name), so their placements should honor
> > backup-directory-alist which is currently ignored.
>
> I don't know if they should. The current behavior is a long-standing
> one. But more opinions are welcome.
The main problem is the user may not want these files at all.
I usually look at a particular version then close the buffer, I don't
want a file created and having such files polluting the directory. I
just want to see the contents.
I'd say more people use log to look up something in a certain version
than actually wanting to get a certain version on disk.
So there's two possible solutions:
1. Add an option to control if backup-directory-alist is honored by
these files and this can be off by default to keep current default
behavior.
2. Do not create files at all on disk, just read the selected
version's contents into a new buffer. The user can decide if he wants
to just look at the file and then close the buffer, or if he wants the
given version on disk then he can save the buffer.
The 2nd option seems better, since it gives control to the user to do
with the buffer as he wishes.
[-- Attachment #2: Type: text/html, Size: 1467 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#37223: 26.2; vc does not honor backup-directory-alist
2019-09-14 19:20 ` ndame
@ 2019-09-19 20:22 ` Juri Linkov
2019-11-13 20:47 ` Juri Linkov
0 siblings, 1 reply; 5+ messages in thread
From: Juri Linkov @ 2019-09-19 20:22 UTC (permalink / raw)
To: ndame; +Cc: 37223@debbugs.gnu.org, Dmitry Gutov
> 2. Do not create files at all on disk, just read the selected
> version's contents into a new buffer. The user can decide if he wants
> to just look at the file and then close the buffer, or if he wants the
> given version on disk then he can save the buffer.
>
> The 2nd option seems better, since it gives control to the user to do
> with the buffer as he wishes.
Please try a new option 'vc-find-revision-no-save' added in Emacs 27.
If you like it, then this report could be closed.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#37223: 26.2; vc does not honor backup-directory-alist
2019-09-19 20:22 ` Juri Linkov
@ 2019-11-13 20:47 ` Juri Linkov
0 siblings, 0 replies; 5+ messages in thread
From: Juri Linkov @ 2019-11-13 20:47 UTC (permalink / raw)
To: ndame; +Cc: 37223@debbugs.gnu.org, Dmitry Gutov
tags 37223 + fixed
close 37223 27.0.50
quit
>> 2. Do not create files at all on disk, just read the selected
>> version's contents into a new buffer. The user can decide if he wants
>> to just look at the file and then close the buffer, or if he wants the
>> given version on disk then he can save the buffer.
>>
>> The 2nd option seems better, since it gives control to the user to do
>> with the buffer as he wishes.
>
> Please try a new option 'vc-find-revision-no-save' added in Emacs 27.
> If you like it, then this report could be closed.
No response within last 2 months, so I guess everything is alright,
thus closing.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-11-13 20:47 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-08-29 19:55 bug#37223: 26.2; vc does not honor backup-directory-alist ndame
2019-09-14 0:40 ` Dmitry Gutov
2019-09-14 19:20 ` ndame
2019-09-19 20:22 ` Juri Linkov
2019-11-13 20:47 ` Juri Linkov
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.