avoid beware of the leopard situation

* Display a warning message when a remote uses a protocol, such as
  git://, that git-annex does not support. Silently skipping such a
  remote was confusing behavior.

  It sets annex-ignore, so the warning is only displayed once.

* Also display a warning message when a remote, without a known uuid,
  is located in a directory that does not currently exist, to avoid
  silently skipping such a remote.

  This is a bit more debatable, since git-annex get will say,
  try making repository available. And since it does not set annex-ignore,
  the warning will be displayed repeatedly. It's also an extreme edge case,
  I don't think I've ever seen it happen in real life.
This commit is contained in:
Joey Hess 2020-05-04 13:01:11 -04:00
parent 5d407aa5a4
commit f9ed30de3b
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 61 additions and 11 deletions

View file

@ -175,3 +175,6 @@ Already posted above
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Well... it did work for git's local protocol...
> [[done]], this was not really a bug, but I have added a warning message
> --[[Joey]]

View file

@ -0,0 +1,26 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2020-05-04T16:13:02Z"
content="""
git-annex cannot possibly support operation over the git protocol, because
that protocol does not have any way to add an extension such as git-annex
to it.
So git-annex currently completely ignores git:// repositories, the same as
it would any git repository using some other foreign protocol.
(eg rsync or a protocol added by a git extension)
This is actually identical behavior to if the remote had "url =
/media/whatever" and the drive was unmounted after the repo was cloned.
git-annex is not able to discover a uuid for the remote, and so it does
not know the remote contains the content, and so it does not say anything
about not being able to get the content from the remote, because it
never tried. IOW, this is a "beware of the leopard" situation.
So, it would better for this to be handled the same way that a ssh remote
that lacks git-annex-shell is handled, by explicitly setting annex-ignore
on first use and displaying a warning. (Although it should not set
annex-ignore for the /media/whatever case, because the drive may later get
mounted again.)
"""]]