On Fri, Jun 26, 2015 at 6:56 PM, Jeff King wrote:
> On Fri, Jun 26, 2015 at 05:37:35PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
>> This is where the "fun" is. The legacy behavior is, if $GIT_WORK_TREE is
>> not set but $GIT_DIR is, cwd is chosen as worktree's top. If you happen
>> to stand at worktree
Junio C Hamano writes:
> But I am not sure if it is true for our children (e.g. hooks,
> filters etc. that is spawned by us). With this change, they inherit
> GIT_WORK_TREE and no GIT_DIR, in such a case. If they set GIT_DIR
> themselves for their own use, perhaps arranging to work in somewhere
Nguyễn Thái Ngọc Duy writes:
> This is where the "fun" is. The legacy behavior is, if $GIT_WORK_TREE is
> not set but $GIT_DIR is, cwd is chosen as worktree's top. If you happen
> to stand at worktree's top when you do this, all is well.
It is not legacy, though. It is how things were designed
Nguyễn Thái Ngọc Duy writes:
> Bottom line is, when $GIT_DIR is set, $GIT_WORK_TREE should be set too
> unless there's no work tree. But setting $GIT_WORK_TREE inside
> set_git_dir() may backfire. We don't know at that point if work tree is
> already configured by the caller. So set it when work
On Fri, Jun 26, 2015 at 05:37:35PM +0700, Nguyễn Thái Ngọc Duy wrote:
> This is where the "fun" is. The legacy behavior is, if $GIT_WORK_TREE is
> not set but $GIT_DIR is, cwd is chosen as worktree's top. If you happen
> to stand at worktree's top when you do this, all is well. If you are in
> a s
In the test case, we run setup_git_dir_gently() the first time to read
$GIT_DIR/config so that we can resolve aliases. We'll enter
setup_discovered_git_dir() and may or may not call set_git_dir() near
the end of the function, depending on whether the detected git dir is
".git" or not. This set_git_
6 matches
Mail list logo