On Thu, Feb 25, 2016 at 3:43 AM, David Turner <dturner@xxxxxxxxxxxxxxxx> wrote: >> > > > > I'm not sure I get this comment. D/F conflicts are no longer >> > > > > a >> > > > > thing >> > > > > for lmdb backend, right? >> > > > >> > > > I'm trying to avoid the lmdb backend creating a set of refs >> > > > that >> > > > the >> > > > files backend can't handle. This would make collaboration with >> > > > other >> > > > versions of git more difficult. >> > > >> > > It already is. If you create refs "foo" and "FOO" on case >> > > sensitive >> > > file system and clone it on a case-insensitive one, you face the >> > > same >> > > problem. We may have an optional configuration knob to prevent >> > > incompatibilities with files backend, but I think that should be >> > > done >> > > (and enforced if necessary) outside backends. >> > >> > Sure, the current state isn't perfect, but why make it worse? >> >> I see it from a different angle. The current state isn't perfect, but >> we will be moving to a better future where "files" backend may >> eventually be deprecated. Why hold back? >> >> But this line of reasoning only works if we have a new backend >> capable >> of replacing "files" without regressions or introducing new >> dependency. Which is why I suggest a new backend [1] (or implement >> Shawn's RefTree if it's proven as good with small repos) >> >> I have no problem if you want to stay strictly compatible with >> "files" >> though. >> >> [1] http://thread.gmane.org/gmane.comp.version-control.git/285893/foc >> us=286654 > > Won't RefTree have the same d/f conflict issue? It's trees all the way down if I understand it correctly, so yes RefTree should have d/f conflict issue as well. -- Duy -- 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