Your message dated Thu, 14 Nov 2024 16:34:52 +0800 with message-id <[email protected]> and subject line Re: Bug#959506: resolved upstream has caused the Debian Bug report #959506, regarding git-annex: `git annex add` sometimes treats non-dotfiles in dotdirs as dotfiles to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 959506: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959506 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: git-annex Version: 8.20200330-1 Severity: normal -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Maintainer, I use git to keep $HOME in version control, and git-annex to version sensitive files whose contents I do not want kept in git, e.g. `.netrc`. My repository thus contains several dotfiles and "dotdirs". The rules for which files are sensitive and which aren't aren't easily described as a simple matching expression, so I leave `annex.largefiles` unset. I expect to be able to specifically use `git add` to add files to git, and `git annex add` to add files to the annex. After upgrading the repository format to v8, `git annex add` sometimes treats ordinary files stored in a dotdir the same as it treats dotfiles – adding them to native git and saying they are non-large files, even when `annex.largefiles` is not configured. I am aware that dotfiles are forced to git by default unless I set `annex.dotfiles`, but I do not expect this to happen with non-dotfiles, even if they are located within dotdirs. Sample transcript: $ cd `mktemp -d -t` $ git init . Initialized empty Git repository in /tmp/tmp.Meciv7SAMH/.git/ $ git annex init init (scanning for unlocked files...) ok (recording state in git...) $ git config --unset annex.largefiles $ git config --unset annex.dotfiles $ git config -l | grep -F annex annex.backends=SHA256E annex.uuid=0b024138-de95-426f-905a-97f2f5e84cb5 annex.version=8 filter.annex.smudge=git-annex smudge -- %f filter.annex.clean=git-annex smudge --clean -- %f $ mkdir .foo $ echo a > .foo/bar $ echo b > .foo/baz $ echo c > .foo/quux $ git annex add .foo/bar add .foo/bar (non-large file; adding content to git repository) ok (recording state in git...) $ git config annex.dotfiles true $ git annex add .foo/baz add .foo/baz ok (recording state in git...) $ git config annex.dotfiles false $ cd .foo $ git annex add quux add quux ok (recording state in git...) In this transcript, I would have expected the call `git annex add .foo/bar` to also add the file to the annex, not to git, irrespective of whether I had `annex.dotfiles` set or not. (Confusingly, the diagnostic message talks about large and non-large files, which initially had me think that `annex.largefiles` had been set to some default value somewhere.) The call `git annex add .foo/baz` however shows that git-annex does depend on `annex.dotfiles` here, unlike in the `cd .foo && git annex add quux` case (as it should, in the latter). To me, this looks like git-annex erroneously classifies dotfiles as all paths which begin with a dot, irrespective of whether they contain directory separators or not. Regards, Marco - -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages git-annex depends on: ii curl 7.68.0-1 ii git 1:2.26.2-1 ii libc6 2.30-4 ii libffi7 3.3-4 ii libgmp10 2:6.2.0+dfsg-4 ii libmagic1 1:5.38-4 ii libsqlite3-0 3.31.1-5 ii netbase 6.1 ii openssh-client 1:8.2p1-4 ii rsync 3.1.3-8 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages git-annex recommends: pn aria2 <none> ii bind9-host 1:9.16.2-3 pn git-remote-gcrypt <none> ii gnupg 2.2.20-1 ii lsof 4.93.2+dfsg-1 pn nocache <none> Versions of packages git-annex suggests: pn adb <none> pn bup <none> pn libnss-mdns <none> pn magic-wormhole <none> pn tahoe-lafs <none> pn tor <none> pn uftp <none> pn xdot <none> pn youtube-dl <none> - -- no debconf information -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTBvAUu2rK/NpMBRakyyKA6JHNekwUCXq5rXAAKCRAyyKA6JHNe k2shAP9UBQE2TofuG++ikZVfHXb/5lWT4jSmm/lFnvGaD9mZtwEA5FSqo+X+Ytod sj07cC6bnf3rOFgRfg0+qmZ3AkC9rgE= =nlXQ -----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---Version: 10.20241031-1 Hello, On Wed 13 Nov 2024 at 02:11pm -04, Joey Hess wrote: > I have fixed the inconsistent git-annex behavior when run in a dotdir. > I recommend closing this bug when git-annex > 10.20241031 is packaged. Thanks for the update. -- Sean Whitton
--- End Message ---
_______________________________________________ Pkg-haskell-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-haskell-maintainers
