On Sat, 2016-02-20 at 09:58 +0700, Duy Nguyen wrote: > > On Fri, 2016-02-19 at 09:54 +0700, Duy Nguyen wrote: > > > On Fri, Feb 19, 2016 at 3:23 AM, David Turner < > > > dturner@xxxxxxxxxxxxxxxx> wrote: > > > > > > +static int read_per_worktree_ref(const char *submodule, > > > > > > const > > > > > > char > > > > > > *refname, > > > > > > + struct MDB_val *val, int > > > > > > *needs_free) > > > > > > > > > > From what I read, I suspect these _per_worktree functions > > > > > will be > > > > > identical for the next backend. Should we just hand over the > > > > > job > > > > > for > > > > > files backend? For all entry points that may deal with per > > > > > -worktree > > > > > refs, e.g. lmdb_resolve_ref_unsafe, can we check ref_type() > > > > > first > > > > > thing, if it's per-worktree we call > > > > > refs_be_files.resolve_ref_unsafe() > > > > > instead? It could even be done at frontend level, > > > > > e.g. refs.c:resolve_ref_unsafe(). > > > > > > > > > > Though I may be talking rubbish here because I don't know how > > > > > whether > > > > > it has anything to do with transactions. > > > > > > > > The reason I did it this way is that some ref chains cross > > > > backend > > > > boundaries (e.g. HEAD -> refs/heads/master). But if we have > > > > other > > > > backends later, we could generalize. > > > > > > Crossing backends should go through frontend again, imo. But I > > > don't > > > really know if it's efficient. > > > > It's pretty tricky to maintain state (e.g. count of symref > > redirects) > > across that barrier. So I'm not sure how to do it cleanly. > > I notice files backend does pretty much the same thing. "files" > backend looks more like two backends combined in one, one is files, > the other is packed-refs. And it looks like we could solve it by > providing a lower level api, read_raw_ref() or something, that > retrieves the ref without any validation or link following. More on > this later. That basica pproach appears to mostly work. I'll send another series with read_raw_ref as soon as I'm done applying all comments on this series. > > > > > 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? > OK how about we keep resolve_ref_1() whole and split real backend > code > out? Something like these three patches (only built, did not test). A > bit ugly with continue_symlink, but it's just demonstration. I did this a somewhat different way -- will see what you think when I send it. -- 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