Re: [PATCH] require_work_tree: Look for top-level instead of is-inside-work-tree

[Michael J Gruber <git@drmicha.warpmail.net>]

Tor Arne Vestbø venit, vidit, dixit 28.07.2010 18:47:
> The documentation describes require_work_tree as guarding against
> bare repositories, and that's also the way it's used from porcelain
> such as git-rebase. When implemented using --is-inside-work-tree
> the samantics change, causing git-rebase to fail if run from outside
> GIT_WORK_TREE, even if GIT_WORK_TREE is valid.
> 
> Signed-off-by: Tor Arne Vestbø <tor.arne.vestbo@nokia.com>
> ---
>  git-sh-setup.sh     |    2 +-
>  t/t1501-worktree.sh |    9 +++++++++
>  2 files changed, 10 insertions(+), 1 deletions(-)
> 
> diff --git a/git-sh-setup.sh b/git-sh-setup.sh
> index 6131670..f8e4428 100644
> --- a/git-sh-setup.sh
> +++ b/git-sh-setup.sh
> @@ -141,7 +141,7 @@ cd_to_toplevel () {
>  }
>  
>  require_work_tree () {
> -	test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = true ||
> +	test -n "$(git rev-parse --show-toplevel 2>/dev/null)" ||
>  	die "fatal: $0 cannot be used without a working tree."
>  }
>  

An alternative which does not change the established behavior of
require_work_tree would be changing the order of require_work_tree and
cd_to_top_level in the callers where possible along the lines of

http://mid.gmane.org/96abf622ca2cf92998ce4ed393ccaa75d95dd9a8.1279112025.git.git@drmicha.warpmail.net

which got lost somehow. (The other callers, as mentioned by Junio, would
need to be changed differently, e.g. by moving cd_to... earlier.)

Another problem I noticed back then (I was away since) was that a
relative GIT_WORK_TREE is left in place after a cd_to_top_level and
messes things up completely - it does not seem to be relative to
GIT_DIR. So, there seems to be more to fix in this area.

Cheers,
Michael