diff options
| author |  http://id.clacke.se/ <clacke@web> | 2013-12-17 22:09:35 +0000 |
|---|---|---|
| committer |  admin <admin@branchable.com> | 2013-12-17 22:09:35 +0000 |
| commit | aabd070c2f5b48606a5819f916301fcfe8bb9e39 (patch) | |
| tree | 87bdb395ea8db63d1eba041e4c68116ccb53707f /doc | |
| parent | 1c79d095f7bd8fdfbe35c5449e64762f1ad46429 (diff) | |
clarify which parts were added in the edit; strike the "lost URL" problem, which `migrate` probably takes care of
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/bugs/feature_request:_addhash.mdwn | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/doc/bugs/feature_request:_addhash.mdwn b/doc/bugs/feature_request:_addhash.mdwn index 78e132d0a..e818a3327 100644 --- a/doc/bugs/feature_request:_addhash.mdwn +++ b/doc/bugs/feature_request:_addhash.mdwn @@ -13,9 +13,9 @@ I have a big repo of files I have added using `addurl --fast`. I download the fi ### Workaround -In both these cases, what I can do is <del>unlock (maybe?) or unannex (definitely) all of the files, and then re-add them using the new hash</del> use `migrate` to relink the files using the new scheme. In both use cases this means I now risk having duplicates in various clones of the repo, and would have to clean them up with `drop-unused` -- after first having re-copied them from a repo that has them under the new hash or `migrate`d them in each clone using the pre-migration commit; Either way is problematic for special remotes, in particular glacier. I also lose the continuity of the history of that object. +In both these cases, what I can do is <del>unlock (maybe?) or unannex (definitely) all of the files, and then re-add them using the new hash</del> <em>use `migrate` to relink the files using the new scheme</em>. In both use cases this means I now risk having duplicates in various clones of the repo, and would have to clean them up with `drop-unused` -- after first having re-copied them from a repo that has them under the new hash <em>or `migrate`d them in each clone using the pre-migration commit; Either way is problematic for special remotes, in particular glacier</em>. I also lose the continuity of the history of that object. -In use case 2 I also lose the URLs of the files and would have to re-add them using `addurl`. +<del>In use case 2 I also lose the URLs of the files and would have to re-add them using `addurl`.</del> <em>This is probably not true when using `migrate`.</em> ... which brings me to the proposed feature. |