From dd5611b737960dc63c4208c3248f0e1e44d4d3ca Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 25 Oct 2018 16:51:52 -0400 Subject: [PATCH] devblog --- doc/devblog/day_551__v6_or_v7.mdwn | 19 +++++++++++++++++++ doc/todo/smudge.mdwn | 21 +++++++++++---------- 2 files changed, 30 insertions(+), 10 deletions(-) create mode 100644 doc/devblog/day_551__v6_or_v7.mdwn diff --git a/doc/devblog/day_551__v6_or_v7.mdwn b/doc/devblog/day_551__v6_or_v7.mdwn new file mode 100644 index 0000000000..05a35ebfc1 --- /dev/null +++ b/doc/devblog/day_551__v6_or_v7.mdwn @@ -0,0 +1,19 @@ +In the `delaysmudge` branch, I've implemented the delayed worktree update in +the post-merge/post-checkout hooks for v6. It works very well! + +In particular, with annex.thin set, checking out a branch +containing a huge unlocked file does a fast hard link to the file. + +Remaining problem before merging that is, how to get the new hooks installed? Of +course `git annex init` and `git annex upgrade` install them, but I know plenty +of people have v6 repositories already, without those hooks. + +So, would it be better to bump up to v7 and install the hooks on that upgrade, +or stay on v6 and say that it was, after all, experimental up until now, and +so the minor bother of needing to run `git annex init` in existing v6 repositories +is acceptable? If the version is bumped to v7, that will cause some pain +for users of older versions of git-annex that won't support it, but those old +versions also have pretty big gaps in their support for v6. I'm undecided, +but leaning toward v7, even though it will also mean a lot of work to update +all the documentation, as well as needing changes to projects like datalad that use +git-annex. Feedback on this decision is welcomed below... diff --git a/doc/todo/smudge.mdwn b/doc/todo/smudge.mdwn index 90fa46762d..44f1dcd88f 100644 --- a/doc/todo/smudge.mdwn +++ b/doc/todo/smudge.mdwn @@ -37,20 +37,20 @@ git-annex should use smudge/clean filters. v6 mode Fatal or can we live with needing to run a git-annex command to populate the files after those commands? - Optionally: Use the filterdriver interface during checkout. Unfortunately that - interface is slower for cleaning during git add (see - [[todo/Long_Running_Filter_Process]]), but if the smudge filter is not - providing git with the file content and letting a - post-checkout/post-merge/post-commit hooks - populate the files, using filterdriver would avoid git running many - git-annex smudge processes, greatly speeding up large checkouts. - git add could be left slow, with git-annex add being the fast path, - until the filterdriver interface is improved. Or, make "git annex proxy" - use the filterdriver interface for checkout. + > implemented on the `delaysmudge` branch now (My enhanced smudge/clean patch set also fixed this problem, in a much nicer way...) +* Optionally: Use the filterdriver interface during checkout. Unfortunately that + interface is slower for cleaning during git add (see + [[todo/Long_Running_Filter_Process]]), but since the smudge filter is not + providing git with the file content any more, using filterdriver would + avoid git running many git-annex smudge processes, greatly speeding up large + checkouts. git add could be left slow, with git-annex add being the fast path, + until the filterdriver interface is improved. Or, make "git annex proxy" + use the filterdriver interface for checkout. + * When git runs the smudge filter, it buffers all its output in ram before writing it to a file. So, checking out a branch with a large v6 unlocked files can cause git to use a lot of memory. @@ -66,6 +66,7 @@ git-annex should use smudge/clean filters. v6 mode The annex.thin idea above could work around this problem. + > implemented on the `delaysmudge` branch now ## other warts