summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2011-07-04 12:27:47 -0400
committerGravatar Joey Hess <joey@kitenet.net>2011-07-04 12:27:47 -0400
commitbd54dadb0b92945db9fc004d03d1fb32a453225c (patch)
treebf345de7207f9830466d18e66d154de5c4115ea8
parentde408626b72b0bdb98cf1534d7406910318516c2 (diff)
response
-rw-r--r--doc/bugs/annex_unannex__47__uninit_should_handle_copies.mdwn10
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]]