On Fri, Oct 28, 2011 at 23:44, Joey Hess <j...@kitenet.net> wrote:

> git log git-annex..origin/git-annex fails, so both are *not* there.
> (git branch may show them, which means nothing when your repository is
> corrupted)

Ah. Sorry, then.

> What I meant to say is that the only place that git-annex looks to
> determine the UUID of the current repository is .git/config. Of course
> it *stores* information about a UUID in various places -- in your
> example you told it to store a description "test" for that UUID, so
> status displays that even if it doesn't know of any repository that has
> that UUID. Notice it did not say "test (here)"

Makes sense. Thanks :)

Is there any technical reason that would make

    git annex init "test" --uuid=foo

impossible? That way, I could re-use the UUID when I _know_ it's OK to
reuse them. As an aside you are using v1 UUIDs, I hugely prefer v4. Is
there any way to change which are being generated?

> The best that could be done is to add a fourth trust state that is like
> untrusted UUIDs but causes them to be hidden from view. But this would
> mean additional work, to handle this edge case -- and simply changing
> the description of a dead repository seems to work nearly as well.

My mental implementation did exactly that: Introduce a hidden trust state.

Unfortunately, this is not an edge case, for me. I have a total of
three repos that died on me which means 75% of the repos I have, at
the moment. After fixing everything up again, I will have 3/7
permanently gone repos in the repo graph.

Unless there's a way to init while a given UUID?

vcs-home mailing list

Reply via email to