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 2024-04-18 10:05:37 -04:00
commit 7701bca2f6
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 103 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

54
doc/bugs/Dropping_filename_extensions_with_more_than_4_char.mdwn Normal file
View file

@ -0,0 +1,54 @@
### Please describe the problem.
The file extension of annexed files are dropped if they have more than four characters (like `.blend` files)
All `*E` backends are affected but `WORM` seems to work.
### What steps will reproduce the problem?
[[!format sh """
mkdir foo && cd foo
git init
git annex init
echo '* annex.backend=SHA256E' > .gitattributes
echo '* annex.largefiles=(largerthan=0)' >> .gitattributes
echo 'foo' > foo.abc
echo 'bar' > bar.abcd
echo 'baz' > baz.abcde
echo 'faz' > faz.abcdef
git annex add .
ls -l
"""]]
Outputs
[[!format sh """
total 16
lrwxrwxrwx 1 foo bar 188 Apr 18 11:52 bar.abcd -> .git/annex/objects/z2/jk/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730.abcd/SHA256E-s4--7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730.abcd
lrwxrwxrwx 1 foo bar 178 Apr 18 11:52 baz.abcde -> .git/annex/objects/MZ/Fq/SHA256E-s4--bf07a7fbb825fc0aae7bf4a1177b2b31fcf8a3feeaf7092761e18c859ee52a9c/SHA256E-s4--bf07a7fbb825fc0aae7bf4a1177b2b31fcf8a3feeaf7092761e18c859ee52a9c
lrwxrwxrwx 1 foo bar 178 Apr 18 11:52 faz.abcdef -> .git/annex/objects/6Z/zG/SHA256E-s4--0206bf5fc94a74ae22c2c0e93ad1b578ae7f16cb52fb470cddf1f0d324c6bbf3/SHA256E-s4--0206bf5fc94a74ae22c2c0e93ad1b578ae7f16cb52fb470cddf1f0d324c6bbf3
lrwxrwxrwx 1 foo bar 186 Apr 18 11:52 foo.abc -> .git/annex/objects/Mq/J5/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.abc/SHA256E-s4--b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c.abc
"""]]
### What version of git-annex are you using? On what operating system?
- Tested with Ubuntu 22.04
- git-annex v8 from original ubuntu ppa
- git-annex-standalone v10 from neurodebian ppa
### Please provide any additional information below.
[[!format sh """
$ git annex version
git-annex version: 10.20240227-1~ndall+1
build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
operating system: linux x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
local repository version: 10
"""]]

15
doc/bugs/documentation_typo_in_git_annex_find.mdwn Normal file
View file

@ -0,0 +1,15 @@
### Please describe the problem.
`git annex find --help` incorrectly documents `--copies REMOTE`, the REMOTE should be NUMBER.
### What steps will reproduce the problem?
`git annex find --help | grep -- --copies`
### What version of git-annex are you using? On what operating system?
10.20240129
### 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)
git annex is awesome, was always awesome and will always be awesome. I appreciate all the work going into it.

8
doc/bugs/documentation_typo_in_git_annex_find/comment_1_afb7c20d07eb58647d0dba265ee31998._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="nobodyinperson"
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
subject="Everyone can fix typos in the docs"
date="2024-04-18T05:21:42Z"
content="""
Btw you can edit the documentation yourself, just click the EDIT button at the top of the page.
"""]]

8
doc/bugs/documentation_typo_in_git_annex_find/comment_2_13a5aa9163d1fd392bf52484c6eb4d90._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="ErrGe"
avatar="http://cdn.libravatar.org/avatar/37423d3bfd69af2cda23d194ec74f991"
subject="but I'm talking about --help, isn't that in the source code?"
date="2024-04-18T13:07:40Z"
content="""
I'm talking about the output of a --help command, that has to be in the source code somewhere, no?
"""]]

18
doc/todo/force_star_topology_on_a_repository/comment_8_f840a405028df2630a7c8eac5091833f._comment Normal file
View file

@ -0,0 +1,18 @@
[[!comment format=mdwn
username="ErrGe"
avatar="http://cdn.libravatar.org/avatar/37423d3bfd69af2cda23d194ec74f991"
subject="hook idea implementation is cool, but usage is not so simple for the enduser"
date="2024-04-18T01:17:02Z"
content="""
Sorry for resurrecting this after 2 years, I somehow forgot this discussion was ongoing.
So, first of all, thank you so much for taking the time to writing up a very cool server side solution for the problem. Do I understand your proposal correctly, that basically on the server we would always store a git-annex rewritten branch as if it was correctly written by the client, no matter what the clients do on their own in their own git-annex branches, right?
And since all the merging in git-annex is line based, this constant rewrite wouldn't confuse the clients when they `git fetch --all` + `git annex merge`? Wouldn't the merge commits in `gitk git-annex` be very weird to understand?
So what I don't understand, is that if we do this on the central server side, then yes, the rewrite on the server is good, but when the offending client does a `git fetch` + `git annex merge`, it will create a merge commit with 2 parents. Will we also straighten that out automatically and delete the \"stupid\" side on the next push? Doesn't this mean, that debugging just becomes more confusing and this client will create longer and longer side branches on its graphical branch view of `gitk git-annex`?
Let me reflect back to your \"comment 5\", where you asked the very valid question of what to do in case of difference of opinions. I think the correct solution is to implement the override feature (in .git/config, as you said), and let it completely happen. If the only way for unwanted UUIDs to appear in my central repo is for someone to use this extra feature, I'm OK with that. I want to prevent accidents, and I certainly don't want to prevent expert power-users achieving their goals when needed, so local override (even if the end result is pushed back), is 100% fine.
Now, that I'm thinking about this as a \"reasonable difference of opinion to have\", an interesting \"solution\" comes to mind, that opens up of course a very big discussion: why in the design of git-annex there is only ONE AND ONLY git-annex branch? Git has orphan branches, and it would be legit to say, that different group of people working in a repo, have different opinion of \"view of the annex\", e.g. they think different repos (or special remotes) are important or unimportant for them. I mention this question not really seriously as a proposal to redesign, but I'm sure that you had this idea sometime in the past, and if you have some insight or revelations, I'd be happy to read it.
"""]]