[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
 nickname="Richard"
 subject="comment 1"
 date="2014-01-01T21:32:56Z"
 content="""
Such a class of repositories would be very useful, indeed.

A good name would probably be, in descending order:

* ephemeral
* volatile
* transient
* fleeting

It would be somewhere in between 'untrusted' and 'dead'.

I can see two approaches working nicely, here:

1. Local location log
2. Local location log in another branch / directory
3. No location log

In the first case, location data would be added to the local location log, but any `git annex sync` or similar would parse the location log and strip out all mentions of the UUID in question.
This would be somewhat slower when synching, but would ensure that all operations which rely on local logs operate normally.

In the second case, location data would be kept in a different location.
This would have the benefit of a clean separation and quicker merges, but induces overhead for lookups.
On the other hand, if those lookups are wrapped cleanly, only those functions would need to know about the different locations.

In the last case, no local logs would be kept.


All in all, I think I would prefer the first option.

The one thing that's hard/impossible by design is for other remotes to strip out the data.
As the repository would not be known to other remotes, they would simply continue the carry the data.
This can be worked around by setting the repository to "dead".
Ephemeral repositories would not correct "dead" info about themselves; they _would_ start behaving normally once set to trusted, semit-trusted, or untrusted, though.


Richard
"""]]