responses

This commit is contained in:
Joey Hess 2011-02-27 12:17:19 -04:00
parent 22c8dfcd3f
commit b14ad63381
2 changed files with 26 additions and 1 deletions

View file

@ -7,3 +7,12 @@ A range argument, such as `1-1845`, possibly combined with other argument types
I work around this lack as I want to drop all unused files anyway by something like this:
git annex unused | grep -o -P "^ [0-9]+" | xargs git annex dropunused
> It's designed to be used with `seq`. There's an example in the
> [[walkthrough]], and of course multiple seq calls can be used to
> specifiy multiple ranges. So:
git annex dropunused `seq 1 9` `seq 11 1845`
> I don't see adding my own range operations to be an improvement worth
> making; it'd arguably only be a complication. --[[Joey]] [[done]]

View file

@ -1 +1,17 @@
`git annex migrate` leaves old, unlinked backend versions lying around. It would be great if these were purged automatically somehow.
`git annex migrate` leaves old, unlinked backend versions lying around. It
would be great if these were purged automatically somehow.
> Yes, this is an issue mentioned in the [[walkthrough#index14h2]].
>
> Since multiple files can point to the same content, it could be that
> only one file has been migrated, and the content is still used. So
> the content either has to be retained, or an operation as expensive
> as `git annex unused` used to find it something else still uses it.
>
> Rather than adding such an
> expensive operation to each call to migrate, I focused on hard-linking
> the values for the old and new keys, so that the old keys don't actually
> use any additional resources (beyond an extra inode).
>
> This way a lot of migrations can be done, and only when you're done you
> can do the more expensive cleanup pass if you want to. --[[Joey]]