On Tue, Jul 08, 2014 at 11:48:06AM -0700, Junio C Hamano wrote:
> I'd say that "if you have foo/bar you cannot have foo" may have
> started as an implementation limitation, but the interoperability
> requirement with existing versions of Git and with existing
> repositories makes it necessary to enforce it the same way as other
> rules such as "you cannot have double-dots in name, e.g. foo..bar"
> or "no branches whose name begins with a dash", neither of which
> comes from any filesystem issues. That a rule can be loosened with
> one new backend does not at all mean it is a good idea to loosen it
> "because we can" in the first place.
To me it makes sense to to have it as an option, for two reasons:
1. If you want to pay the compatibility cost (e.g., because you work
with a defined set of users on a small project and can dictate how
they set their git options), you get the extra feature.
2. It provides a migration path if we eventually want to move to a
default backend that allows it.
I admit that I don't care _too_ much, though. My main desire for it is
not to store two live branches that overlap, but to store reflogs for
deleted branches without conflicting with live branches.
And of course all of this is getting rather ahead of ourselves. We do
not have _any_ alternate backends yet, nor even yet the infrastructure
to make them.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html