Dreadfully early this morning I developed a plan for a way to finish the
last v6 blocker, that works around most of the problems with git's smudge
interface. The only problem with the plan is that it would make both git
stash
and git reset --hard
leave unlocked annexed files in an
unpopulated state when their content is available. The user would have to
run git-annex afterwards to fix up after them. All other git checkout,
merge, etc commands would work though.
Not sure how I feel about this plan, but it seems to be the best one so far, other than going off and trying to improve git's smudge interface again. I also wrote up ?git smudge clean interface suboptiomal which explains the problems with git's interface in detail.
I have been using V6 more and more over the past weeks, and it is working pretty well for me so far.
If you are now on the final straight, how will parallelization be triggered (i.e. git annex add --jobs ...) when everything runs (or could run) implicitly through the normal Git API.
Thanks for making this happen!
Well,
git annex add -J
works of course..git add
doesn't have a way to parallelize, nor does git checkout.It might be useful to parallelize
git annex smudge --update
which updates unlocked files in the work tree. I guess it should already be mostly disk bound when it's copying files and parallalizing that would likely only worsten things due to seeking (on spinning rust), but it may have some parallizable overhead when it's making annex.thin hardlinks. It would need to be controlled via a git config flag or something since it gets run internally.