BF: obtain information about annex special remotes also from annex journal#6135
Conversation
…urnal An alternative to datalad#6133 implementation which first forces git-annex to commit. The use case was detected while working on datalad/datalad-crawler#112 to accompany datalad#6105 . Although we could have easily "fixed" the test in datalad-crawler, I consider the approach of going around git-annex commands to interrogate git-annex metadata to be fragile, in particular for such a case as here: some other command could have been ran in alwayscommit=false mode, and information in git-annex branch might not yet reflect actual state of git-annex. Ideally we should avoid doing such "going around git-annex", but ATM there is no git-annex command which would "expose" all this information.
Codecov Report
@@ Coverage Diff @@
## maint #6135 +/- ##
===========================================
- Coverage 85.97% 56.19% -29.79%
===========================================
Files 312 312
Lines 42215 42494 +279
===========================================
- Hits 36296 23878 -12418
- Misses 5919 18616 +12697
Continue to review full report at Codecov.
|
mih
left a comment
There was a problem hiding this comment.
This LGTM. Thx!
However, I want to remind about a comment from Joey
Also reading .git/annex/journal/ will miss configs of private remotes, which are stored in a separate journal and never reach the git-annex branch.
This should be mentioned in the docs, at least. We are not using this yet, but soon "ephemeral clones" will be private annex repos, and then any special remote configured in them would still be invisible to the method. Ping #5835
An alternative to #6133 implementation
which first forces git-annex to commit.
The use case was detected while working on datalad/datalad-crawler#112
to accompany #6105 .
Although we could have easily "fixed" the test in datalad-crawler, I consider
the approach of going around git-annex commands to interrogate git-annex
metadata to be fragile, in particular for such a case as here: some other
command could have been ran in alwayscommit=false mode, and information in
git-annex branch might not yet reflect actual state of git-annex. Ideally we
should avoid doing such "going around git-annex", but ATM there is no git-annex
command which would "expose" all this information.