diff options
author | Joey Hess <joey@kitenet.net> | 2011-07-04 12:27:47 -0400 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2011-07-04 12:27:47 -0400 |
commit | bd54dadb0b92945db9fc004d03d1fb32a453225c (patch) | |
tree | bf345de7207f9830466d18e66d154de5c4115ea8 | |
parent | de408626b72b0bdb98cf1534d7406910318516c2 (diff) |
response
-rw-r--r-- | doc/bugs/annex_unannex__47__uninit_should_handle_copies.mdwn | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/doc/bugs/annex_unannex__47__uninit_should_handle_copies.mdwn b/doc/bugs/annex_unannex__47__uninit_should_handle_copies.mdwn index 6d1799cd7..751e1afa9 100644 --- a/doc/bugs/annex_unannex__47__uninit_should_handle_copies.mdwn +++ b/doc/bugs/annex_unannex__47__uninit_should_handle_copies.mdwn @@ -6,3 +6,13 @@ However, if 2 copies are unannexed, only one is restored, the other becomes a br so my plan is to unninit this repo, delete the .git dir, and then annex everything, as I don't mind the history). Rafaƫl + +> The only way for git-annex to support this in its current state would be +> for the unannex command to copy the file content from the annex, rather +> than moving it out. Then multiple links to the same content could be +> unannexed. +> +> But, this would be slower, and would depend on a later `unused` and +> `dropunused` to actually remove the content. While doable, by use case +> for unannex is more to quickly undo a mistaken add, and it's unlikely there +> are multiple symlinks to the same content in this situation. --[[Joey]] |