Michael Haggerty <[email protected]> writes: > If I understand correctly, you consider the decision of where a > particular reference should be stored to be a kind of "business logic" > decision that should live outside of the refs module. I don't think it > is so important whether this knowledge is inside or outside of the refs > module (I can live with it either way).
I think I misspoke. The decision to make a particular reference, e.g. HEAD or 'master' branch, a per-workspace one or a repo-wide one, should not be made by individual refs backend (i.e. lower-half of the refs module). It could still be the responsibility of the upper-half of the refs module and that _feels_ more kosher. But without actual implementation of the interface between upper- and lower-half of the refs module yet (as we only have fs based backend that is tightly integrated within the refs module and nothing else right now), I do not yet see a clear implementation for the "is this thing common?" table Duy did that decides where things go for everything except "refs/" part while letting the upper-half of the refs module to take responsiblity of that decision for refs. For one thing, "the refs module decides what is in refs/, Duy's table decides everything else " is not even the right partition, in the presence of things like HEAD, logs/, etc. So... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
