Re: git stash doesn't honor --work-tree or GIT_WORK_TREE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Duy Nguyen <pclouds@xxxxxxxxx> writes:

> On Sun, Dec 1, 2013 at 6:12 PM, Thomas Rast <tr@xxxxxxxxxxxxx> wrote:
>> Øystein Walle <oystwa@xxxxxxxxx> writes:
>>> The problem seems to be that git rev-parse --is-inside-work-tree does
>>> not honor these. In fact it doesn't even honor --git-dir or --work-tree.
>>> Judging by the name this may be intentional.
>>
>> Thanks for investigating this.
>>
>> Duy, you are the expert on the worktree detection logic.  Do you know if
>> there is a reason for --is-inside-work-tree to not honor the
>> GIT_WORK_TREE / GIT_DIR overrides?
>
> It should. At the beginning of cmd_rev_parse(), setup_git_directory()
> is called, which will check and follow all GIT_* or their command line
> equivalent. I'll look into this some time later.

Hrm, I'm wrong, and it's not clear what to actually do in this case.
--is-inside-work-tree works as claimed: if we can detect a git
repository and your current directory is inside it, you are "inside a
worktree".

The problem here is that shell scripts that want to do something with a
worktree tend to call require_work_tree in git-sh-setup:

require_work_tree () {
	test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = true ||
	die "fatal: $0 cannot be used without a working tree."
}

However, when an explicit GIT_WORK_TREE is in effect, that seems a bit
silly.  The _intent_ of that command is "I need a worktree to work
with".  But what it currently checks is something completely different,
namely "am I _inside_ the worktree".

--show-cdup might be a better candidate, because it actually (and
despite what the docs suggest, sigh) shows the path to the worktree as
with --show-toplevel for the case where you are not --is-inside-work-tree.

Which means that the output --show-cdup is in fact not necessarily "up"
from the worktree, but something you could cd to to get to its top.

Long story short, this might work (and it passes tests):


diff --git i/git-sh-setup.sh w/git-sh-setup.sh
index 190a539..47c7f1d 100644
--- i/git-sh-setup.sh
+++ w/git-sh-setup.sh
@@ -192,8 +192,12 @@ require_work_tree_exists () {
 }
 
 require_work_tree () {
-	test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = true ||
+	test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = true &&
+	return 0
+	cdup="$(git rev-parse --show-cdup 2>/dev/null)"
+	test -z "$cdup" &&
 	die "fatal: $0 cannot be used without a working tree."
+	cd "$cdup"
 }
 
 require_clean_work_tree () {


But it would give require_work_tree somewhat interesting and unintuitive
side effects.

-- 
Thomas Rast
tr@xxxxxxxxxxxxx
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]