annex.largefiles: configuring mixed content repositories git-annex git-annex ikiwiki 2019-09-29T22:08:29Z Since which version does this apply? acbg 2016-03-03T16:16:28Z 2016-03-03T16:16:28Z <p>I use version 5.20140412, and I've tried the annex.largefiles in .gitattributes, but doesn't work. Every file is added to .git/annex/objects, including the ones that are excluded in .gitattributes.</p> <p>I've just started using git-annex so maybe I'm doing something wrong...</p> same problem workspace 2016-03-04T20:44:26Z 2016-03-04T20:44:26Z <p>I have the same problem: the annex.largefiles is ignored by "git add" when set in .gitattributes allthouch git check-attr does list it.</p> <p>but it works when set with git config annex.largefiles</p> <p>git annex version 6.20160126</p> comment 3 joey 2016-03-07T17:24:14Z 2016-03-07T17:23:19Z <p>The first version to support largefiles in .gitattributes was 6.20160211, so both the above commenters just have too old a version.</p> how to recursively exclude files from git-annex (.gitattributes) christophfischer 2016-06-21T11:42:37Z 2016-06-21T11:42:37Z <p>Hello</p> <p>it took me some time to figure out how to exclude directories matching a specific structure within the .gitattributes file:</p> <pre><code>**/some_dir/**/below_this_dir_is_everything_in_plane_text/**/* annex.largefiles=nothing </code></pre> <p>Maybe it helps someone else. (In case this way is the intended way)</p> Git-annex ignores annex.largefiles in .gitattributes joern.mankiewicz 2017-03-20T20:58:12Z 2017-03-20T20:58:12Z <p>Hi guys!</p> <p><em>sigh</em></p> <p>Currently I am pulling my hair, maybe anybody here can clear things up a bit. I tried to setup a brand new mixed content repo with git-annex but it bluntly ignores my .gitattributes and annexes everything. When I set largefiles in config everything is fine and restrictions are applied right, in .gitattributes even a "* annex.largefiles=nothing" has no effect. All attributes show up right with git check-attr, I double checked. <img src="" alt=":-/" /> Same thing with a newly initialized minimal example repo.</p> <p>I tried git-annex as distributed by openSUSE and the current stand-alone-package (in case it's a distribution bug), too. So no clues here, too.</p> <p>Output of git annex version:</p> <p>git-annex version: 6.20170302-gb35a50cca build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi 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 SHA1E SHA1 MD5E MD5 WORM URL remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external</p> <p>System: OpenSUSE Tumbleweed Linux 4.9.3-1-default #1 SMP PREEMPT Thu Jan 12 11:32:53 UTC 2017 (2c7dfab) x86_64 x86_64 x86_64 GNU/Linux</p> <p>Any ideas? After trying around for hours I am somewhat flabberghasted. Did I miss some config- or buildoption to enable support for .gitattributes?</p> <p>Kind regards</p> <p>Jörn</p> comment 6 joey 2017-03-20T21:17:38Z 2017-03-20T21:16:30Z <p>@joern.mankiewicz, you need to file a bug report with enough information to reproduce your problem.</p> <p>annex.largefiles in .gitattributes works fine:</p> <pre><code>joey@darkstar:~/tmp&gt; git init ttt Initialized empty Git repository in /home/joey/tmp/ttt/.git/ joey@darkstar:~/tmp&gt; cd ttt joey@darkstar:~/tmp/ttt&gt; git annex init init ok (recording state in git...) joey@darkstar:~/tmp/ttt&gt; echo '* annex.largefiles=nothing' &gt; .gitattributes joey@darkstar:~/tmp/ttt&gt; touch foo joey@darkstar:~/tmp/ttt&gt; git annex add foo add foo (non-large file; adding content to git repository) ok (recording state in git...) </code></pre> comment 7 joey 2017-03-20T21:19:47Z 2017-03-20T21:18:24Z <p>Note that if annex.largefiles is set in git config (including global git config), it overrides the .gitattributes setting. So a reasonable guess would be that you set it in the git config.</p> Beware global configurations! joern.mankiewicz 2017-03-20T22:47:50Z 2017-03-20T22:47:50Z <p>Thanks, joey.</p> <p>Your last comment brought me onto the right track. The Problem was not in the repository, but an old stale global .gitconfig in my homedir. I just checked $XDG_CONFIG_HOME/git/config were currently my global git-config is residing and totaly forgot about this old config. Stupid me!</p> <pre><code>git config --show-origin --get annex.largefiles </code></pre> <p>was my savior here as it clearly indicated that there is indeed a (unintended) config setting and where to find the file. So i can strongly recommend anybody experiencing strange behavior to try this one-liner. It might have saved me hours of time.</p> <p>Thanks for your help! <img src="" alt=":)" /></p> <p>Cheers</p> <p>Jörn</p> Adopting "git annex add" as default command in workflow davicastro 2018-03-08T11:21:55Z 2018-03-08T11:21:55Z <p>Hi, from technical point of view, are there any drawbacks/limitations on adopting a workflow of everyone in the project using "git annex add" and relying on the annex.largefiles settings instead of them having to use the separate commands? * I would use repo v5 as repo v6 seems to still need work to do, and I don't need it's features. I just would like to avoid human error of people not using by mistake regular git add for bigfiles. I understand that repo v6 would allow, but I don't like it's default behavior of using unlocked mode when I add things with git add (although it would properly annex the files, but in unlocked mode these files would occupy space in the work copy, and I don't want that). Thanks.</p> Re: Adopting "git annex add" as default command in workflow joey 2018-08-09T19:49:45Z 2018-08-09T19:46:22Z <p>@davicastro yes, using git-annex add for adding both kinds of files is workflow this is about. Other than git add features like <code>--interactive</code> I see no need to ever use git add once you have this set up.</p> Can conversion to/from annexed be made easier? branchable 2019-09-29T22:04:32Z 2019-09-29T22:04:32Z <p>IMHO it's somewhat user-unfriendly and error-prone to have to remember a sequence of three commands to convert an unannexed file to annexed, or vice-versa. So it would be nice if there were git-annex commands to do this in one go.</p> <p>In fact, I would expect <code>git annex add</code> to handle adding to the annex, and <code>git annex unannex</code> to do the opposite. Are there good reasons why they should not be made to do that? Even if there are, aren't those subcommands already doing very similar things? In which case maybe the solution would be to add extra option to each to enable this behaviour? For example <code>--force</code> or something like that in order to tell it to ignore <code>annex.largefiles</code> (although for <code>add</code> that is already used to allow adding ignored files, so we probably shouldn't conflate the two cases under one option).</p> Follow-up thought branchable 2019-09-29T22:08:29Z 2019-09-29T22:08:29Z Afterthought on the immediately preceding comment - if the intention of <code>unannex</code> is to reverse <code>add</code>, then IMHO <code>unadd</code> or <code>undo-add</code> seem like more logical choices. Renaming to one of these would free up <code>unannex</code> for the conversion use case. But I appreciate that this is potentially confusing for users already used to <code>unannex</code>'s current behaviour, so I expect the idea will be rejected.