unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Andrii Kolomoiets <andreyk.mad@gmail.com>
Cc: 43464@debbugs.gnu.org
Subject: bug#43464: 28.0.50; vc: Error calling vc-revert for repo root
Date: Tue, 13 Oct 2020 14:59:38 +0300	[thread overview]
Message-ID: <74547795-7592-7c33-af81-326144bb0bc6@yandex.ru> (raw)
In-Reply-To: <m2sgakld7r.fsf@gmail.com>

On 11.10.2020 23:28, Andrii Kolomoiets wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>>> Can you please advice me what this change should look like?  Get rid
>>> of calling 'vc-call'?
>>
>> Yes. How about the attached patch?
> 
> Small fix: THEN and ELSE blocks of the '(if dir...' should be swapped.

Ah yes, thanks for noticing.

> Does those kind of changes should be applied to any function that uses
> 'vc-call' and can be called on dirs?

I think so. Since none of them should work on directories now, it should 
be accompanied with some doc changes as well.

> Is there any reason to use 'vc-backend' at all?
 >
> 'vc-responsible-backend' will call 'vc-backend' on a file that is not a
> directory.

Well, vc-backend is certain to be faster, on average. That is one 
advantage. Minus one disk loopup, or minus extra network interaction 
with Tramp (that's where it might really hurt).

I don't have a very strong argument here, except the current code works, 
and it should be easier to annotate the exceptions where we do want to 
handle directories. And while we do that, consider the performance 
implications for each case.

>>> In this case the function 'vc-version-backup-file'
>>> must be changed as well.
>>
>> Does it actually make sense to use it on a directory?
> 
> Looks like it make sense for CVS backend.  Take a look at
> 'vc-cvs-stay-local-p'.

It might be desired for CVS (to cut down on network traffic), but how 
would it work? The function is supposed to return a backup file name. 
But we don't create backup files for whole directories. Only for 
individual files.

>> Something like that. Or 'git init' inside a subdirectory. Not a
>> frequent occurrence, but if we start using directories and files
>> interchangeably in more places, we are likely to start caching other
>> properties on them, too. So it's better to use a different function to
>> detect which backend a directory belongs to.
> 
> In this case `vc-call` must use that function, right?

No, vc-call won't be used. Like in the patch I sent previously.

>> Also, your patch makes vc-registered work on directories.
> 
> How is that?  'vc-registered' is still returns nil for directories.  The
> changes affects only the side effect of it.

Oh, now I finally understand what it's doing.

You can probably see how it's not ideal control flow (call a function, 
see it return nil, and then rely on its undocumented side-effect).

So if we can avoid doing that and still fix the bug, the alternative 
approach should be preferable.





  reply	other threads:[~2020-10-13 11:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-17  7:29 bug#43464: 28.0.50; vc: Error calling vc-revert for repo root Andrii Kolomoiets
2020-09-17 16:10 ` Lars Ingebrigtsen
2020-09-18  9:00 ` Dmitry Gutov
2020-09-18  9:30   ` Andrii Kolomoiets
2020-09-18 13:30     ` Dmitry Gutov
2020-09-18 15:45       ` Andrii Kolomoiets
2020-09-22 19:48         ` Dmitry Gutov
2020-09-24  7:15           ` Andrii Kolomoiets
2020-09-30  9:13             ` Andrii Kolomoiets
2020-10-04 22:32             ` Dmitry Gutov
2020-10-05  6:02               ` Andrii Kolomoiets
2020-10-05 10:19                 ` Dmitry Gutov
2020-10-07 13:16                   ` Andrii Kolomoiets
2020-10-07 22:47                     ` Dmitry Gutov
2020-10-11 20:28                       ` Andrii Kolomoiets
2020-10-13 11:59                         ` Dmitry Gutov [this message]
2020-09-18 13:18   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=74547795-7592-7c33-af81-326144bb0bc6@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=43464@debbugs.gnu.org \
    --cc=andreyk.mad@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).