Quoting Mike Rappazzo <rappa...@gmail.com>:
On Thu, Feb 25, 2016 at 5:54 PM SZEDER Gábor <sze...@ira.uka.de> wrote:
Some scripts can benefit from not having to deal with the possibility
of relative paths to the repository, but the output of 'git rev-parse
--git-dir' can be a relative path. Case in point: supporting 'git -C
<path>' in our Bash completion script turned out to be considerably
more difficult, error prone and required more subshells and git
processes when we had to cope with a relative path to the .git
directory.
Help these use cases and teach 'git rev-parse' a new
'--absolute-git-dir' option which always outputs a canonicalized
absolute path to the .git directory, regardless of whether the path is
discovered automatically or is specified via $GIT_DIR or 'git
--git-dir=<path>'.
Signed-off-by: SZEDER Gábor <sze...@ira.uka.de>
---
Documentation/git-rev-parse.txt | 4 ++++
builtin/rev-parse.c | 29 +++++++++++++++++++++--------
t/t1500-rev-parse.sh | 17 ++++++++++-------
3 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-rev-parse.txt
b/Documentation/git-rev-parse.txt
index b6c6326cdc7b..fb06e3118570 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -216,6 +216,10 @@ If `$GIT_DIR` is not defined and the current directory
is not detected to lie in a Git repository or work tree
print a message to stderr and exit with nonzero status.
+--absolute-git-dir::
+ Like `--git-dir`, but its output is always the canonicalized
+ absolute path.
+
--git-common-dir::
Show `$GIT_COMMON_DIR` if defined, else `$GIT_DIR`.
After working a little bit with rev-parse [1], I feel that this might
be better served as a
stand-alone option. Consider that in addition to --git-dir, the
options --git-common-dir,
--git-path, and --git-shared-index produce relative paths.
I propose that it might make more sense to use something like
`--abs-path` to indicate
that the result should include an absolute path (or we could also
just spell out
`--absolute-path`). That way we don't have to add additional options
for any other type
that might want an absolute path.
Do you have a specific use case in mind, where scripts struggle because
in some cases '--git-dir', '--git-common-dir' or '--git-path' return a
relative path? (Assuming that these options produce the right relative
paths, of course. At the moment some don't in some cases, but your
patches elsewhere will eventually take care of that.)
As far as git is concerned, relative paths are relative to the current
working directory of the git process or script. If a script is invoked
as 'git -C subdir myscript', then the CWD is changed accordingly by the
main git process first going into the given directory before starting
the script.
Now, though I wrote that generalizing "some scripts" and "these use
cases" in the commit message, I really only meant the completion
script, because it is rather special in that it's executed in the
user's interactive shell environment. This means that it can't just
simply 'cd' around and it has to cope with 'git -C subdir' options on
it's own, because in that case the CWD of the git processes invoked
from the completion script will be different from the CWD of the
user's shell. That's the situation where a relative path returned
from 'git rev-parse --git-dir' causes troubles.
I can't really see other scripts in this situation, and I really don't
expect that the completion script would need any path other than the
path to the git repository, i.e. it only needs '--absolute-git-dir'.
Therefore I think that a separate '--absolute-path' option would offer
little benefit, but at the same time would pose considerable
complications, more on that below.
git rev-parse --git-dir --abs-path
git rev-parse --git-common-dir --absolute-path
'git rev-parse's command line option parsing loop not just parses an
option but in a lot of cases performs the necessary action right away,
before examining any subsequent options. In the above example
it would print the path to the .git directory as soon as it encounters
'--git-dir' while iterating through the command line options, before
even noticing that there is an '--absolute-path' option as well. If
anything, then the other way around:
git rev-parse --absolute-path --git-dir
And if we were to go this route, then there are a bunch of questions
about the gory details that would have to be cleared up first:
Should the presence of an '--absolute-path' option influence all
subsequent path-returning options or just the one immediately
following it? I.e. should all these options always return an
absolute path?
git rev-parse --absolute-path --git-dir --git-common-dir \
--git-path objects
What about this, i.e. when there are other option(s) between
'--absolute-path' and a path-returning option?
git rev-parse --absolute-path --is-bare-repository --git-dir
I'd think they should all return an absolute path then.
Now, should '--absolute-path' have an effect on '--show-prefix'
and '--prefix' as well?
git rev-parse --absolute-path --show-prefix
git rev-parse --absolute-path --prefix t/ README
Luckily, options after a filename are not allowed, so we don't even
have to think about cases like
git rev-parse --prefix t/ README --absolute-path Makefile
as it would error out anyway.
Would we need a '--no-absolute-path' (or '--relative-path', perhaps?)
option to turn off the effect of a previous '--absolute-path', e.g.
git rev-parse --absolute-path --git-dir \
--no-absolute-path --git-common-dir
If yes, should a '--no-abolute-path' force subsequent path-returning
options to return a relative path even when they by default would
return an absolute path, e.g.:
git -C t/ rev-parse --no-absolute-path --git-dir
Or should it return a relative path even when paths are explicitly
specified as absolute paths?
git --git-dir=/absolute/path/to/repo.git rev-parse
--no-absolute-path --git-dir
git rev-parse --prefix /home/szeder/src/git/t/ --no-absolute-path README
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
