[resend: urgh, I somehow missed the git-list when replying, so it is cc'd here] On Tue, Aug 26, 2008 at 09:35:50AM +0200, Michael J Gruber wrote: > "Typical" developers track source code in the proper sense (somewhere in > $HOME); on local file systems; mostly on machines where they have root > access, or least can get extra accounts (for gitosis) or a port for "git > daemon" etc; they collaborate with peers for whom basically the same > assumptions apply. > > Now think of a user say in academics, who tracks "source code" for > scientific papers (somewhere in $HOME) but also needs to track, e.g., > central web pages or other "sources" where he has partial write access > but can't have ".git" in place (and shouldn't change ownership & Actually, I do all of those things, and I don't use the work-tree config variable or command line options at all. :) I think the general advice with things like web access is "don't just dump your git stuff into a production area; instead, build and/or install from your git work tree into your production area". Because things like merges _can_ leave your files in a broken state. But I do recognize that there are some special circumstances where that isn't possible, and you are willing to accept the tradeoff. E.g., if the checkout is extremely large and you can't afford another copy, if you have clueless collaborators who can't understand a build procedure. And even though I expect those cases to be the exception, it seems a shame for git not to support split git-dir/work-tree setups because we really are 99% there. This code has been the source of a number of problems. I think what is really needed is somebody to look carefully at the git startup sequence and figure out a sane set of rules for the order of: - looking at env variables - looking at config - figuring out GIT_DIR and GIT_WORK_TREE - chdir'ing to top level of work tree if necessary Because we obviously have some corner cases where very confusing things are happening. This is on my long term todo list, but my git time is very short at least for the next few months. I think it would be great if somebody else wanted to take the lead on this, and I would be happy to give pointers about some of the corner cases we have already seen. -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
