Re: [PATCH] Preserve cwd in setup_git_directory()

Hi,

On 7/25/08, Nguyen Thai Ngoc Duy [off-list ref] wrote:

On 7/24/08, Johannes Schindelin [off-list ref] wrote:
 > Hi,
 >
 >  On Thu, 24 Jul 2008, Nguyen Thai Ngoc Duy wrote:
 >
 >  > On 7/24/08, Johannes Schindelin [off-list ref] 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