responsen
This commit is contained in:
parent
0dcbe51ed2
commit
4d7802bff7
2 changed files with 16 additions and 0 deletions
|
@ -6,3 +6,10 @@ Upgrading from v1 to v3:
|
|||
ok
|
||||
|
||||
A whirly would be preferable, imo.
|
||||
|
||||
> Erm, I'm pretty sure you were the one who asked for there to be some
|
||||
> progress dots, Richard.
|
||||
>
|
||||
> I'm not particularly interested in implementing a whirley that would only
|
||||
> be used in this one place, in code that very few users are going to run
|
||||
> again. I could remove the dots.. --[[Joey]]
|
||||
|
|
|
@ -4,3 +4,12 @@ As uninit does not need to actually write out any data, just remove it, it shoul
|
|||
git-annex: Repository version 2 is not supported. Upgrade this repository: git-annex upgrade
|
||||
|
||||
If the repo happens to be broken, this essentially locks in data.
|
||||
|
||||
> No, because you can always check out the version of git-annex you need
|
||||
> for that repository.
|
||||
>
|
||||
> uninit, as implemented, runs unannex on every file and then does some
|
||||
> cleanup. The cleanup does not need to write state, but the unannex does.
|
||||
> And it depends on the object directory layout, which has changed between
|
||||
> versions. So supporting old versions in this code would complicate it
|
||||
> quite a lot. I don't want to go there. --[[Joey]]
|
||||
|
|
Loading…
Reference in a new issue