On Tue, Mar 26, 2013 at 11:20:58AM -0700, Junio C Hamano wrote: > When you are in ~/mail/subdir, because GIT_DIR alone does not give > you to specify where the root-level of the working tree is, you had > to "cd .." before running "GIT_DIR=~/git/mail.git git ...". By > setting GIT_WORK_TREE to point at ~/mail once, you can freely chdir > around inside subdirectories of ~/mail without losing sight of where > the root-level is, and if your ~/git/mail.git is tied to a single > working tree (and that is true in this example, it is always ~/mail), > you can even set core.worktree in ~/git/mail.git/config. Yeah, I did not talk about moving around to multiple working trees with the same GIT_DIR. I have done that, but I do not know of a workflow where it is a good practice, and not just a one-off hack. > > We could do so now, as long as we provide an escape hatch (and I think > > spelling that hatch as GIT_WORK_TREE=. is probably sane, but I am open > > to other suggestions). > > If we were to do so, GIT_WORK_TREE=. would be the most sensible, but > I do not think it is worth breaking. Why do these people set GIT_DIR > without setting GIT_WORK_TREE in the first place? I don't think there is a good reason. The argument, as I see it, is mainly that doing so can be confusing and destructive, and there is not a big benefit to allowing it. I am not sure I am convinced it is worth the breakage, either. Curious as to what the code would look like, I made a straw-man series, which will follow. Note that I am not suggesting we do this, but still merely thinking about the idea. Notably, at the end of the series a number of tests fail. A few of them are testing the GIT_DIR behavior explicitly (I fixed up t1510, but did not hunt down all of the spots), but a few of them are legitimate breakages in scripts. For example, difftool is broken because it sets GIT_DIR. That gives us an indication of what kinds of breakages we would see in real-world third-party scripts. > > The problem is not with "clean", which just happens to be a destructive > > command, but rather with the notion of what the git tree is when you > > provide GIT_DIR. > > Yes, "git add ." would happily add random cruft to your index, which > is equally bad. Eh, I would say it is bad, but not equally bad to removing your entire home directory. ;) -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