Hi, On 7/25/08, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote: > On 7/24/08, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > Hi, > > > > On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote: > > > > > On 7/24/08, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > > > > > > > On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote: > > > > > > > > > When GIT_DIR is not set, cwd is used to determine where .git is. If > > > > > core.worktree is set, setup_git_directory() needs to jump back to > > > > > the original cwd in order to calculate worktree, this leads to > > > > > incorrect .git location later in setup_work_tree(). > > > > > > > > I do not understand. core.worktree is either absolute, in which case > > > > there is no problem. Or it is relative to where the config lives, no? > > > > > > The problem is GIT_DIR is not absolute in this case. So cwd must stay > > > where git dir is until it is absolute-ized by setup_work_tree(). > > > > > > I do not see GIT_DIR being set in your test case at all. > > > > I do not see how get_git_work_tree() ro get_relative_cwd() should ever be > > allowed to chdir(). > > > > _If_ they were (which I strongly doubt), they should chdir() back > > themselves. > > > > I now wasted easily 30 minutes just trying to make sense of your patch and > > your response. And I am still puzzled. > > > > Your commit message was of no help. > > > Alright, let's look at the code. > > 1. cwd is moved to toplevel working directory by setup_git_directory_gently() > 2. setup_git_env() by default will set git_dir variable as ".git" as > part of check_repository_format_gently() > 3. now in setup_git_directory() finds out core.worktree, it chdir() > to get relative prefix > 4. setup_work_tree() sees that git_dir is not absolute path, it makes > git_dir absolute > > If in step 3, it does not chdir(), step 4 will be right. In this case, > step 3 does chdir() and not going back, access to git repository will > fail as Geoff Russell discovered. > -- > > Duy > There seem to be plenty of things happening here which I know nothing about, which is really why I hit the problem in the first place. I was pretty surprised to find that my command line switch (--work-tree) was being stored in the config file, which ended up causing the problem. Duy thinks he can fix this, which is fine, but as a matter of principle, I'm not keen on command line switches being magically saved for me when I didn't ask for this to happen. The reason for using a command line switch is because I want to override default behaviour on this execution, if I wanted to change the default behaviour, then I'd set values in the config file. Whatever you decide, I reckon its pretty magical to have a software problem, send an email to a list and get the solution in 45 minutes. I've never got that service from any other piece of software (or hardware)! Cheers, Geoff Russell -- 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
