mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2020-02-10 16:03:48 -08:00
commit 933cb573df
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
9 changed files with 99 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
doc/bugs/annex.genmetadata_should_default_to_true/comment_4_615bb36fb8e2958c001fc6df997b2928._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="reasons not to have annex.genmetadata default to true"
date="2020-02-10T18:40:52Z"
content="""
Some reasons `annex.genmetadata` should *not* default to true: (1) ordinary git does not preserve file modtimes, probably on purpose: if you have some kind of `make` process, you want `git update` to cause updated files to have updated modtimes, not the modtimes from when the files were added to git, so that `make` can detect the change and update downstream files; (2) as @joey noted, potentially wasteful bloat, especially for repos with many files; (3) two different copies of a file may have different modtimes, but all copies must have the same git-annex metadata, because metadata is attached to the [[key|backends]], which for most backends is computed from file contents.
The WOM backend stores the modtime in the key, but then does not store checksums. If [[todo/external_backends]] are implemented, you could make one that includes both the checksum and the modtime in the key.
"""]]

8
doc/forum/Annex_v7_repos_and_plain_git_files/comment_1_3bf39b5e6990d4343d9154465d951a77._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="adding plain git files in v7 repos"
date="2020-02-09T18:08:30Z"
content="""
What git-annex version are you using, and what are your git config settings? In the current version, if `annex.largefiles` is not set, or if `annex.gitaddtoannex` is set to `false`, `git add` should [[add all files to plain git|forum/lets_discuss_git_add_behavior/#comment-37e0ecaf8e0f763229fd7b8ee9b5a577]].
"""]]

15
doc/forum/Annex_v7_repos_and_plain_git_files/comment_2_a0628a013b57c00ea449b40b93edd385._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="oliv5"
avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
subject="comment 2"
date="2020-02-09T22:59:35Z"
content="""
Thks for pointing me to the \"git add v7\" very interesting thread. It explains everything.
I'm using git-annex version: 7.20190912 (the default in Ubuntu 19.10 packages).
Neither annex.gitaddtoannex nor annex.largefiles were set in my repo. In this version, I have to set annex.largefiles to \"nothing\" to get the expected behaviour, annex.gitaddtoannex true/false does not change anything. Of course, I verified this behaviour in a fresh new repo without any config change/hack.
But even if annex.gitaddtoannex does not change anything right now, I'll set it to false, in case later version of git-annex uses it.
"""]]

8
doc/forum/Annex_v7_repos_and_plain_git_files/comment_3_6095eaa58aa298aca72237381f567ffb._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="updating git-annex"
date="2020-02-10T00:05:00Z"
content="""
You can use [[install/conda]] to install a recent git-annex version that supports `annex.gitaddtoannex`.
"""]]

8
doc/forum/Annex_v7_repos_and_plain_git_files/comment_4_fd1a3658ed6f3b6af2297c768b3f1ac2._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="git-annex ubuntu package"
date="2020-02-10T02:07:10Z"
content="""
P.S. It's a bit concerning if 7.20190912 is the default git-annex version in a common distro: it's the version most likely to confuse users with the changed `git add` behavior. Can this be fixed? Is it definitely the default version? I don't know much about Ubuntu packaging, but from [https://packages.ubuntu.com/](https://packages.ubuntu.com/), 19.10 (`focal`) seems to have version [7.20191230](https://packages.ubuntu.com/focal/utils/git-annex)?
"""]]

17
doc/forum/Annex_v7_repos_and_plain_git_files/comment_5_f47fec91d4ceebe653bc3fb221e2f8df._comment Normal file
View file

@ -0,0 +1,17 @@
[[!comment format=mdwn
username="oliv5"
avatar="http://cdn.libravatar.org/avatar/d7f0d33c51583bbd8578e4f1f9f8cf4b"
subject="comment 5"
date="2020-02-10T10:10:06Z"
content="""
Thks for pointing me to Conda, I didn't know it.
About Ubuntu 19.10 old git-annex package, it seems I have the expected revision. I rarely mess with the package manager (only nvidia drivers!), so I don't expect any issue there.
<https://ubuntu.pkgs.org/19.10/ubuntu-universe-amd64/git-annex_7.20190912-1_amd64.deb.html>
<https://packages.ubuntu.com/eoan/git-annex>
Yes, I agree, my git-annex package is an old one. Ubuntu is supposed to be a stable main stream distro, so optional packages like git-annex are not the cutting edge ones. And 19.10 is not a LTS release, you can expect the situation to be worse on 18.04 LTS. Same on Debian, Raspbian etc...
"""]]

8
doc/forum/Annex_v7_repos_and_plain_git_files/comment_6_21648eecfaf9673b25d40327d11f7b59._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="default git-annex version in distros"
date="2020-02-10T18:55:29Z"
content="""
\"you can expect the situation to be worse on 18.04 LTS\" -- if the default version there is before 7.20190912 there is no chance of user confusion, only versions 7.20190912 through 7.20191017 can cause it. I take it it's not possible to change the default version included in existing distributions? Sorry, don't know how Ubuntu/Debian packaging works...
"""]]

5
doc/forum/Recomended_Setup_for_Syncthing_Remote.mdwn Normal file
View file

@ -0,0 +1,5 @@
Hello!
&nbsp;&nbsp;&nbsp;&nbsp; So with Android 10, Syncthing may be facing some issues regarding where we can put our files on the device. However, the Syncthing-Fork from the Google Play store has granular control over when sync tasks can run, which I very much require; I was thinking of combining git-annex and Syncthing by syncing the `.git/annex/objects` directory, but I am still *very* new to this. Can anyone advise me what the best setup would be for the procedure, according to [`syncthing special remote`](https://git-annex.branchable.com/todo/syncthing_special_remote/)?
&nbsp;&nbsp;&nbsp;&nbsp; Thank you kindly for the help!

20
doc/tips/automatically_adding_metadata/comment_10_cf770ba8eed7963f08517877bd460d3f._comment Normal file
View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="max"
avatar="http://cdn.libravatar.org/avatar/ebbd4dd37b341d018077a12e7ccf9fbd"
subject="adding support for additional metadata tools?"
date="2020-02-10T04:45:55Z"
content="""
hi there, sincere gratitude for your work on git-annex.
is it worth considering a more modular setup (maybe a python script :) or even haskell) for working with metadata extractors?
currently it really only supports field-based filtering extractors. i am particularly interested in using (minimally):
mp3info - offers a formatting string for printing but doesn't fit super nicely into the \"want\" fields in shell script. could probably be hacked in.
mp4info - does not seem to offer any native parameters for filtering; would likely need some engineering/thought about how to take in all possible fields then filtering off of those.
alternatively i could just write some personal scripts here, but just thought others would find it useful for auto extracting content from mp3/m4a files. extract doesn't seem to perform as well on these as, say, .flac files.
thanks again!
"""]]