On Sat, Aug 18, 2012 at 01:39:41PM -0700, Junio C Hamano wrote:
> mhag...@alum.mit.edu writes:
>
> > Given that a flag day would anyway be required to add a d/f-tolerant
> > system, I could live with a separate "graveyard" namespace as
> > originally proposed by Jeff.
> >
> > However, I still think that as long as we are making a jump, we could
> > try to land closer to the ultimate destination.
>
> Do we _know_ already what the "ultimate destination" looks like?
>
> If the answer is yes, then I agree, but otherwise, I doubt it is a
> good idea to introduce unnecessary complexity to the system that may
> have to be ripped out and redone.
>
> I didn't get the impression that we know the "ultimate destination"
> from the previous discussion, especially if we discount the tangent
> around "having next and next/foo at the same time" which was on
> nobody's wish, but I may be misremembering things.
Sorry for the slow response on this topic; I was traveling all last week
and am still catching up with emails.
I don't think we know what the ultimate destination looks like. If I had
to choose, it would probably be something like:
refs/heads/next.ref
refs/heads/next/foo.ref
which is easy to read and manipulate. But this is not compatible with
the current system, because:
1. It cannot use ".ref", as that is allowed in ref names currently.
2. This can't co-exist with existing, non-tweaked refs, since
"refs/heads/next" would still conflict (you'd have to instead do
"refs/heads.dir/next.dir/foo".
But since making a change like this would involve bumping the
repositoryformatversion flag _anyway_, so at that point we don't really
have to care about compatibility, and we are free to design what looks
good.
So in other words, I do not think any ultimate destination that I find
palatable would be achievable without making the full format jump
anyway. If all things were equal, I'd say there is no reason not to get
as close as we can. But I find some of the proposals significantly less
readable (in particular, the directory-munging is IMHO much harder to
read). And it is not as if it is buying us anything; you still have to
make a magic translation between a dead log and a live one.
Another option I've considered is simply holding back the graveyard
topic, working on the d/f tolerant storage, and then implementing the
graveyards on top (which is basically free at that point). But as you
note, it is not really a commonly-requested feature. If it were easy,
I'd say let's do it. But the idea of bumping repositoryformatversion for
the first time in git's history just to add a feature nobody wants is
not very appealing to me.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
