> From: Junio C Hamano
> > ... it's not clear why GIT_WORK_TREE exists, ...
>
> The configuration item came _way_ later than the environment, and we
> need to keep users and scripts from old world working, that is why.
OK, that explains a great deal. IIRC, I first became aware that
detached wo
> From: Junio C Hamano
> It was unclear to me which part of our documentation needs updating
> and how, and that was (and still is) what I was primarily interested
> in finding out.
It seems to me that what is missing is a description of the
circumstances under which Git can be run. With Subver
> From: Junio C Hamano
> Now, when you say "the cwd contains the .git directory", do you mean
>
> cd /repositories
> git add ../working/trees/proj-wt1/file
>
> updates "file" in the /repositories/proj.git/index? Or do you mean
> this?
The pattern I use is to have this:
wor...@alum.mit.edu (Dale R. Worley) writes:
>> From: Junio C Hamano
>
>> Side note: without GIT_WORK_TREE environment (or
>> core.worktree), there is no way to tell where the top level
>> is, so you were limited to always be at the top level of
>> your working tree if you use
> From: Junio C Hamano
> Side note: without GIT_WORK_TREE environment (or
> core.worktree), there is no way to tell where the top level
> is, so you were limited to always be at the top level of
> your working tree if you used GIT_DIR to refer to a
> repository that
From: "Jonathan Nieder"
Philip Oakley wrote:
It was Dale that had the problem, I was just suggesting where he might
want to look... ;-)
A bit more looking gave that the cd_to_toplevel () in git-sh-setup.sh
directly uses `git rev-parse --show-toplevel`, which simply returns
work_tree (sta
Philip Oakley wrote:
> A bit more looking gave that the cd_to_toplevel () in git-sh-setup.sh
> directly uses `git rev-parse --show-toplevel`, which simply returns
> work_tree (static char *work_tree; in environment.c, with comment /*
> This is set by setup_git_dir_gently() and/or git_default_confi
From: "Philip Oakley"
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Junio C Hamano"
"Philip Oakley" writes:
... and the detection process for 'toplevel' may not work
properly when in a separated work-tree environment.
Without GIT_WORK_TREE exported to point at the top-level,
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Junio C Hamano"
"Philip Oakley" writes:
... and the detection process for 'toplevel' may not work
properly when in a separated work-tree environment.
Without GIT_WORK_TREE exported to point at the top-level, there is
nothing that le
"Philip Oakley" writes:
> From: "Junio C Hamano"
>> "Philip Oakley" writes:
>>
>>> ... and the detection process for 'toplevel' may not work
>>> properly when in a separated work-tree environment.
>>
>> Without GIT_WORK_TREE exported to point at the top-level, there is
>> nothing that lets us "
From: "Junio C Hamano"
"Philip Oakley" writes:
... and the detection process for 'toplevel' may not work
properly when in a separated work-tree environment.
Without GIT_WORK_TREE exported to point at the top-level, there is
nothing that lets us "detect" it, as the working tree does not have
wor...@alum.mit.edu (Dale R. Worley) writes:
> I must admit I've never seen the design (and I personally doubt that
> the design has ever been written down). But at least the following
> commands work correctly on a detached worktree if the current
> directory contains the .git directory, because
> From: Junio C Hamano
>
> wor...@alum.mit.edu (Dale R. Worley) writes:
>
> > In general, Git commands on a repository with a detached worktree can
> > be executed by cd'ing into the directory containing the .git
> > directory, ...
>
> Eh? News to me; it might happened to have appeared to work
"Philip Oakley" writes:
> ... and the detection process for 'toplevel' may not work
> properly when in a separated work-tree environment.
Without GIT_WORK_TREE exported to point at the top-level, there is
nothing that lets us "detect" it, as the working tree does not have
".git" directory to tel
From: "Junio C Hamano"
wor...@alum.mit.edu (Dale R. Worley) writes:
In general, Git commands on a repository with a detached worktree can
be executed by cd'ing into the directory containing the .git
directory, ...
Eh? News to me; it might happened to have appeared to work by
accident, but t
wor...@alum.mit.edu (Dale R. Worley) writes:
> In general, Git commands on a repository with a detached worktree can
> be executed by cd'ing into the directory containing the .git
> directory, ...
Eh? News to me; it might happened to have appeared to work by
accident, but that is not by design.
In Git, one can set up a repository with a "detached worktree", where
the .git directory is not a subdirectory of the top directory of the
work tree.
In general, Git commands on a repository with a detached worktree can
be executed by cd'ing into the directory containing the .git
directory, and ex
17 matches
Mail list logo
