On Sat, Jul 18, 2015 at 12:03 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > The other one is more heavy. Do we even want to have and expose > GIT_COMMON_DIR environment variable? > > The primary reason why we added GIT_DIR, GIT_OBJECT_DIRECTORY > etc. in the early days of Git was because we didn't exactly know > what kind of layout and flexibility was needed from "various SCMs > that sit on top of Git core", and we wanted to make progress rapidly > without making decisions back then. But it is not 2005 anymore. > > Suppose a file "gitdir: /home/gitster/w/src/.git/worktrees/rerere" > (call that $GIT_DIR) is there, and there is $GIT_DIR/commondir. Is > there any valid reason why somebody may want to use only part of > that arrangement and have a $GIT_COMMON_DIR that points at a place > different from $GIT_DIR/commondir points at to override only a part > of the setting? > > Or perhaps there is a plain vanilla $GIT_DIR that does not have > $GIT_DIR/commondir. Is there any valid reason why somebody may want > to reuse only part of that directory as if it were a linked checkout > and then use $GIT_COMMON_DIR to redirect the access to the meat of > the repository elsewhere? > > The safety that comes from the primary checkout and the secondary > checkouts all knowing everybody else is lost in such a use case, > that is the whole point of adding this new feature. The fact that > $GIT_COMMON_DIR/worktrees/* and $GIT_DIR/commondir reference each > other is what gives us object-prune-safety and multi-checkout-safety. > > Unless I am mistaken, I think a separate GIT_COMMON_DIR environment > variable that can be tweaked by end-user is nothing but a source of > future bugs and user confusion, without giving us any useful > flexibility. The flexibility here is not about extending this feature per se but maybe trying out an entirely different setup. Yes a bunch of safety nets are thrown out of the window if you try it. I guess I still had the 2005 mindset when I designed this. If there is no strong objection to $GIT_COMMON_DIR, I suggest we keep it until we sort out the submodule problem. There are a few options on how to share git repos between submodules that this explicit separation _might_ help. -- 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