Jeff King <peff@xxxxxxxx> writes:
> Changing these scripts to use require_work_tree_exists is
> easy to verify. We immediately call cd_to_toplevel, anyway.
> Therefore no matter which function we use, the state
> afterwards is one of:
>
> 1. We have a work tree, and we are at the top level.
>
> 2. We don't have a work tree, and we have died.
>
> The only catch is that we must also make sure no code that
> ran before the cd_to_toplevel assumed that we were already
> in the working tree.
>
> In this case, we will only have included shell libraries and
> called set_reflog_action, neither of which care about the
> current working directory at all.
>
> Signed-off-by: Jeff King <peff@xxxxxxxx>
> ---
> This is the low-hanging, obviously correct fruit.
I am not absolutely sure about "obviously correct", given that you assume
that cd_to_toplevel does what its name makes you think it does. I've been
wondering if we want to do give a bit more sanity to "cd_to_toplevel" and
"rev-parse --show-toplevel".
$ pwd
/srv/project/git/git.git
$ (cd Documentation/howto && git rev-parse --show-toplevel); echo $?
/srv/project/git/git.git
0
So far so good, however:
$ (cd .git/refs/heads && git rev-parse --show-toplevel); echo $?
0
I do not think this is quite right.
We would probably want to add "rev-parse --show-work-tree", but we would
need to audit the users of cd_to_toplevel before starting to use it. I
wouldn't be surprised if there is a script that creates a temporary work
tree in .git/some/where and runs the scripted Porcelains without setting
GIT_WORK_TREE, relying on the historical behaviour of cd_to_toplevel that
does not really go to the top level.
--
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