Prior to v6, I used git annex add for files that should go into the annex, and git add for files that should be tracked in git normally. With v6, git add silently adds to the annex instead, which surprised me because I didn't expect the file contents to still only reside only on the source computer after a push! I don't have annex.largefiles set, but it seems like this is intended behavior. Is there a way to return to v5 behavior for those two commands? Is it safe to just remove the smudge/clean filter? If so, is there a way to remove it in such a way that it propagates to all repositories? (It's currently set in .git/info/attributes, which overrides .gitattributes).
Having to come up a generic rule for annex.largefiles to cover all of my distinctions is difficult, and it's tedious to re-specify it for each new file. I'd much rather just be able to continue using git as usual, and explicitly choose when to invoke git-annex.
Jim
This is a documented behavior change in v6 mode. I'm willing to listen to arguments that the behavior change is a bad idea, but see below.
To get the old behavior, you can use:
Unfortunately git won't let you alias git add to always pass that switch. But you could alias
git saddor something to use that switch.The same behavior change also makes
git commit -ause git-annex when file contents have changed, rather than the old hacky method which added the files to git and then undid that in a pre-commit hook. So there's quite a nice benefit there.And for that reason it doesn't make sense to add a configuration option to disable it, because such an option would break
git commit -aof modified annexed files.Changing the gitattributes won't work because then the v6 repository won't get annexed files checked out properly.
git annex -abenefit one of performance? I.e. the reason why the pre-commit hook approach was less good was that could be slower?