[PATCH] rev-parse: respect core.hooksPath in --git-path

[PATCH] rev-parse: respect core.hooksPath in --git-path

[Johannes Schindelin]

The idea of the --git-path option is not only to avoid having to
prefix paths with the output of --git-dir all the time, but also to
respect overrides for specific common paths inside the .git directory
(e.g. `git rev-parse --git-path objects` will report the value of
the environment variable GIT_OBJECT_DIRECTORY, if set).

When introducing the core.hooksPath setting, we forgot to adjust
git_path() accordingly. This patch fixes that.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Published-As: https://github.com/dscho/git/releases/tag/git-path-hooks-v1
Fetch-It-Via: git fetch https://github.com/dscho/git git-path-hooks-v1

 path.c                       | 2 ++
 t/t1350-config-hooks-path.sh | 6 ++++++
 2 files changed, 8 insertions(+)

diff --git a/path.c b/path.c
index 17551c4..fe3c4d9 100644
--- a/path.c
+++ b/path.c
@@ -380,6 +380,8 @@ static void adjust_git_path(struct strbuf *buf, int git_dir_len)
 			      get_index_file(), strlen(get_index_file()));
 	else if (git_db_env && dir_prefix(base, "objects"))
 		replace_dir(buf, git_dir_len + 7, get_object_directory());
+	else if (git_hooks_path && dir_prefix(base, "hooks"))
+		replace_dir(buf, git_dir_len + 5, git_hooks_path);
 	else if (git_common_dir_env)
 		update_common_dir(buf, git_dir_len, NULL);
 }
diff --git a/t/t1350-config-hooks-path.sh b/t/t1350-config-hooks-path.sh
index 5e3fb3a..f1f9aee 100755
--- a/t/t1350-config-hooks-path.sh
+++ b/t/t1350-config-hooks-path.sh
@@ -34,4 +34,10 @@ test_expect_success 'Check that various forms of specifying core.hooksPath work'
 	test_cmp expect actual
 '
 
+test_expect_success 'git rev-parse --git-path hooks' '
+	git config core.hooksPath .git/custom-hooks &&
+	git rev-parse --git-path hooks/abc >actual &&
+	test .git/custom-hooks/abc = "$(cat actual)"
+'
+
 test_done
-- 
2.9.2.691.g78954f3

base-commit: 726cc2ba12c4573ab2e623077479c51019e1f3cd

Re: [PATCH] rev-parse: respect core.hooksPath in --git-path

[Jeff King]

On Mon, Aug 15, 2016 at 02:43:18PM +0200, Johannes Schindelin wrote:

> The idea of the --git-path option is not only to avoid having to
> prefix paths with the output of --git-dir all the time, but also to
> respect overrides for specific common paths inside the .git directory
> (e.g. `git rev-parse --git-path objects` will report the value of
> the environment variable GIT_OBJECT_DIRECTORY, if set).
> 
> When introducing the core.hooksPath setting, we forgot to adjust
> git_path() accordingly. This patch fixes that.

Makes sense.

I think you can squash in:

diff --git a/run-command.c b/run-command.c
index 33bc63a..5a4dbb6 100644
--- a/run-command.c
+++ b/run-command.c
@@ -824,10 +824,7 @@ const char *find_hook(const char *name)
 	static struct strbuf path = STRBUF_INIT;
 
 	strbuf_reset(&path);
-	if (git_hooks_path)
-		strbuf_addf(&path, "%s/%s", git_hooks_path, name);
-	else
-		strbuf_git_path(&path, "hooks/%s", name);
+	strbuf_git_path(&path, "hooks/%s", name);
 	if (access(path.buf, X_OK) < 0)
 		return NULL;
 	return path.buf;

as strbuf_git_path() handles this now.

-Peff

Re: [PATCH] rev-parse: respect core.hooksPath in --git-path

[Johannes Schindelin]

Hi Peff,

On Mon, 15 Aug 2016, Jeff King wrote:

> On Mon, Aug 15, 2016 at 02:43:18PM +0200, Johannes Schindelin wrote:
> 
> > The idea of the --git-path option is not only to avoid having to
> > prefix paths with the output of --git-dir all the time, but also to
> > respect overrides for specific common paths inside the .git directory
> > (e.g. `git rev-parse --git-path objects` will report the value of
> > the environment variable GIT_OBJECT_DIRECTORY, if set).
> > 
> > When introducing the core.hooksPath setting, we forgot to adjust
> > git_path() accordingly. This patch fixes that.
> 
> Makes sense.
> 
> I think you can squash in:
> 
> diff --git a/run-command.c b/run-command.c
> index 33bc63a..5a4dbb6 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -824,10 +824,7 @@ const char *find_hook(const char *name)
>  	static struct strbuf path = STRBUF_INIT;
>  
>  	strbuf_reset(&path);
> -	if (git_hooks_path)
> -		strbuf_addf(&path, "%s/%s", git_hooks_path, name);
> -	else
> -		strbuf_git_path(&path, "hooks/%s", name);
> +	strbuf_git_path(&path, "hooks/%s", name);
>  	if (access(path.buf, X_OK) < 0)
>  		return NULL;
>  	return path.buf;
> 
> as strbuf_git_path() handles this now.

Good point.

BTW in light of the discussion we are having elsewhere I just need to
point out that it was *dramatically* faster for me to edit run-command.c,
find "hooks/" and adjust the code manually than it would have been to save
the diff and apply it.

That's because I do not have advanced tooling on top of email (and I also
could not handle mutt, so I am stuck with a not-really-scriptable email
client).

Just sayin'.

Ciao,
Dscho

Re: [PATCH] rev-parse: respect core.hooksPath in --git-path

[Jeff King]

On Tue, Aug 16, 2016 at 02:42:34PM +0200, Johannes Schindelin wrote:

> > I think you can squash in:
> > 
> > diff --git a/run-command.c b/run-command.c
> [...]
> 
> Good point.
> 
> BTW in light of the discussion we are having elsewhere I just need to
> point out that it was *dramatically* faster for me to edit run-command.c,
> find "hooks/" and adjust the code manually than it would have been to save
> the diff and apply it.
> 
> That's because I do not have advanced tooling on top of email (and I also
> could not handle mutt, so I am stuck with a not-really-scriptable email
> client).
> 
> Just sayin'.

There's a flip side, too. It was faster for me to paste in the diff than
it would have been to create a branch, push it to GitHub, and make a PR
on your PR (and then later remember to deal with my PR and branch so as
not to leave them hanging around cluttering up my fork).

I'm definitely sympathetic to people with less exacting email clients,
but I'm not convinced that the GitHub flow is that great if you don't do
the review there in the first place (and even when you do, it's actually
not that great for suggesting things in patch form).

I wonder if public-inbox could have helped here. I think:

  mid=20160815125006.qdssqgd4rzjw4vi5@sigill.intra.peff.net
  curl http://public-inbox.org/git/$mid/raw | git apply

would work, but the question remains of how you find the right
message-id. You can generally pick it out of the MUA's message headers
manually, though I think some MUAs even make seeing the extended headers
hard. But that's going to be a similar problem with any solution that
isn't your MUA: how do you feed the context of the discussion happening
in one place to another tool.

-Peff

[PATCH v2] rev-parse: respect core.hooksPath in --git-path

[Johannes Schindelin]

The idea of the --git-path option is not only to avoid having to
prefix paths with the output of --git-dir all the time, but also to
respect overrides for specific common paths inside the .git directory
(e.g. `git rev-parse --git-path objects` will report the value of the
environment variable GIT_OBJECT_DIRECTORY, if set).

When introducing the core.hooksPath setting, we forgot to adjust
git_path() accordingly. This patch fixes that.

While at it, revert the special-casing of core.hooksPath in
run-command.c, as it is now no longer needed.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Published-As: https://github.com/dscho/git/releases/tag/git-path-hooks-v2
Fetch-It-Via: git fetch https://github.com/dscho/git git-path-hooks-v2
Interdiff vs v1:

 diff --git a/run-command.c b/run-command.c
 index 33bc63a..5a4dbb6 100644
 --- a/run-command.c
 +++ b/run-command.c
 @@ -824,10 +824,7 @@ const char *find_hook(const char *name)
  	static struct strbuf path = STRBUF_INIT;
  
  	strbuf_reset(&path);
 -	if (git_hooks_path)
 -		strbuf_addf(&path, "%s/%s", git_hooks_path, name);
 -	else
 -		strbuf_git_path(&path, "hooks/%s", name);
 +	strbuf_git_path(&path, "hooks/%s", name);
  	if (access(path.buf, X_OK) < 0)
  		return NULL;
  	return path.buf;


 path.c                       | 2 ++
 run-command.c                | 5 +----
 t/t1350-config-hooks-path.sh | 6 ++++++
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/path.c b/path.c
index 17551c4..fe3c4d9 100644
--- a/path.c
+++ b/path.c
@@ -380,6 +380,8 @@ static void adjust_git_path(struct strbuf *buf, int git_dir_len)
 			      get_index_file(), strlen(get_index_file()));
 	else if (git_db_env && dir_prefix(base, "objects"))
 		replace_dir(buf, git_dir_len + 7, get_object_directory());
+	else if (git_hooks_path && dir_prefix(base, "hooks"))
+		replace_dir(buf, git_dir_len + 5, git_hooks_path);
 	else if (git_common_dir_env)
 		update_common_dir(buf, git_dir_len, NULL);
 }
diff --git a/run-command.c b/run-command.c
index 33bc63a..5a4dbb6 100644
--- a/run-command.c
+++ b/run-command.c
@@ -824,10 +824,7 @@ const char *find_hook(const char *name)
 	static struct strbuf path = STRBUF_INIT;
 
 	strbuf_reset(&path);
-	if (git_hooks_path)
-		strbuf_addf(&path, "%s/%s", git_hooks_path, name);
-	else
-		strbuf_git_path(&path, "hooks/%s", name);
+	strbuf_git_path(&path, "hooks/%s", name);
 	if (access(path.buf, X_OK) < 0)
 		return NULL;
 	return path.buf;
diff --git a/t/t1350-config-hooks-path.sh b/t/t1350-config-hooks-path.sh
index 5e3fb3a..f1f9aee 100755
--- a/t/t1350-config-hooks-path.sh
+++ b/t/t1350-config-hooks-path.sh
@@ -34,4 +34,10 @@ test_expect_success 'Check that various forms of specifying core.hooksPath work'
 	test_cmp expect actual
 '
 
+test_expect_success 'git rev-parse --git-path hooks' '
+	git config core.hooksPath .git/custom-hooks &&
+	git rev-parse --git-path hooks/abc >actual &&
+	test .git/custom-hooks/abc = "$(cat actual)"
+'
+
 test_done
-- 
2.9.2.691.g78954f3

base-commit: 07c92928f2b782330df6e78dd9d019e984d820a7

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

[Remi Galan Alfonso]

Hi Johannes,

Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> diff --git a/t/t1350-config-hooks-path.sh b/t/t1350-config-hooks-path.sh
> index 5e3fb3a..f1f9aee 100755
> --- a/t/t1350-config-hooks-path.sh
> +++ b/t/t1350-config-hooks-path.sh
> @@ -34,4 +34,10 @@ test_expect_success 'Check that various forms of specifying core.hooksPath work'
>          test_cmp expect actual
>  '
>  
> +test_expect_success 'git rev-parse --git-path hooks' '
> +        git config core.hooksPath .git/custom-hooks &&

Any reason to not use 'test_config' here?

Thanks,
Rémi

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

Hi Rémi,

On Tue, 16 Aug 2016, Remi Galan Alfonso wrote:

> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> > diff --git a/t/t1350-config-hooks-path.sh b/t/t1350-config-hooks-path.sh
> > index 5e3fb3a..f1f9aee 100755
> > --- a/t/t1350-config-hooks-path.sh
> > +++ b/t/t1350-config-hooks-path.sh
> > @@ -34,4 +34,10 @@ test_expect_success 'Check that various forms of specifying core.hooksPath work'
> >          test_cmp expect actual
> >  '
> >  
> > +test_expect_success 'git rev-parse --git-path hooks' '
> > +        git config core.hooksPath .git/custom-hooks &&
> 
> Any reason to not use 'test_config' here?

Yes: consistency. The rest of the script uses `git config`, not
`test_config`.

Ciao,
Dscho

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

[Remi Galan Alfonso]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Rémi,
> 
> On Tue, 16 Aug 2016, Remi Galan Alfonso wrote:
> 
> > Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> > > diff --git a/t/t1350-config-hooks-path.sh b/t/t1350-config-hooks-path.sh
> > > index 5e3fb3a..f1f9aee 100755
> > > --- a/t/t1350-config-hooks-path.sh
> > > +++ b/t/t1350-config-hooks-path.sh
> > > @@ -34,4 +34,10 @@ test_expect_success 'Check that various forms of specifying core.hooksPath work'
> > >          test_cmp expect actual
> > >  '
> > >  
> > > +test_expect_success 'git rev-parse --git-path hooks' '
> > > +        git config core.hooksPath .git/custom-hooks &&
> >
> > Any reason to not use 'test_config' here?
> 
> Yes: consistency. The rest of the script uses `git config`, not
> `test_config`.

Fine by me, then. Sorry for the noise.

> Ciao,
> Dscho

Ciao,
Rémi

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

[Junio C Hamano]

Remi Galan Alfonso <remi.galan-alfonso@ensimag.grenoble-inp.fr>
writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Hi Rémi,
>> 
>> On Tue, 16 Aug 2016, Remi Galan Alfonso wrote:
>> 
>> > Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>> > > diff --git a/t/t1350-config-hooks-path.sh b/t/t1350-config-hooks-path.sh
>> > > index 5e3fb3a..f1f9aee 100755
>> > > --- a/t/t1350-config-hooks-path.sh
>> > > +++ b/t/t1350-config-hooks-path.sh
>> > > @@ -34,4 +34,10 @@ test_expect_success 'Check that various forms of specifying core.hooksPath work'
>> > >          test_cmp expect actual
>> > >  '
>> > >  
>> > > +test_expect_success 'git rev-parse --git-path hooks' '
>> > > +        git config core.hooksPath .git/custom-hooks &&
>> >
>> > Any reason to not use 'test_config' here?
>> 
>> Yes: consistency. The rest of the script uses `git config`, not
>> `test_config`.
>
> Fine by me, then. Sorry for the noise.

No, thanks for reviewing.  I'll take Dscho's patch as-is but once it
hits 'next', it probably is a good idea to do a separate clean-up
patch on top to use test_config where necessary.

Having said that, this entire script is about constantly changing
the value of that single configuration variable and see how the code
performs, so any new test added after existing ones is expected to
ignore left-over values in the variable and set it to a value of its
own liking.  So I suspect there is no existing "git config" call in
this script, with or without Dscho's patch, that would benefit from
getting converted to test_config.

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

[Remi Galan Alfonso]

Junio C Hamano <gitster@pobox.com> writes:
> Remi Galan Alfonso <remi.galan-alfonso@ensimag.grenoble-inp.fr>
> writes:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>> Hi Rémi,
>>>
>>> On Tue, 16 Aug 2016, Remi Galan Alfonso wrote:
>>>
>>> > Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>>> > > diff --git a/t/t1350-config-hooks-path.sh b/t/t1350-config-hooks-path.sh
>>> > > index 5e3fb3a..f1f9aee 100755
>>> > > --- a/t/t1350-config-hooks-path.sh
>>> > > +++ b/t/t1350-config-hooks-path.sh
>>> > > @@ -34,4 +34,10 @@ test_expect_success 'Check that various forms of specifying core.hooksPath work'
>>> > >          test_cmp expect actual
>>> > >  '
>>> > >  
>>> > > +test_expect_success 'git rev-parse --git-path hooks' '
>>> > > +        git config core.hooksPath .git/custom-hooks &&
>>> >
>>> > Any reason to not use 'test_config' here?
>>>
>>> Yes: consistency. The rest of the script uses `git config`, not
>>> `test_config`.
>>
>> Fine by me, then. Sorry for the noise.
>
> No, thanks for reviewing.  I'll take Dscho's patch as-is but once it
> hits 'next', it probably is a good idea to do a separate clean-up
> patch on top to use test_config where necessary.
>
> Having said that, this entire script is about constantly changing
> the value of that single configuration variable and see how the code
> performs, so any new test added after existing ones is expected to
> ignore left-over values in the variable and set it to a value of its
> own liking.  So I suspect there is no existing "git config" call in
> this script, with or without Dscho's patch, that would benefit from
> getting converted to test_config.

Thanks for checking the ones in this file, considering the lack
of benefits it might not be worth it to change it for now.

I tried to see if the `git config` in other tests were in the
same case or not but the sheer amount made me reconsider. However
taking a look at a couple of random ones, there are some scripts
that would benefit from the conversion.
For example in t3200-branch there is:

    test_expect_success 'git branch with column.*' '
    	git config column.ui column &&
    	git config column.branch "dense" &&
    	COLUMNS=80 git branch >actual &&
    	git config --unset column.branch &&
    	git config --unset column.ui &&
    	cat >expected <<\EOF &&
      a/b/c   bam   foo   l   * master    n     o/p   r
      abc     bar   j/k   m/m   master2   o/o   q
    EOF
    	test_cmp expected actual
    '

The conversion would drop 2 lines in this particular case and
would avoid bleeding the config should `git branch` fail (not
sure how possible that is...).

(I can make a patch for t3200 but that won't be before
days/weeks, so if someone else wants to take care of it I won't
mind)

If I have some time to kill, I'll try looking at a few others but
I won't expect that any time soon.

Thanks,
Rémi

Re: [PATCH v2] rev-parse: respect core.hooksPath in --git-path

[Junio C Hamano]

Remi Galan Alfonso <remi.galan-alfonso@ensimag.grenoble-inp.fr>
writes:

> I tried to see if the `git config` in other tests were in the
> same case or not but the sheer amount made me reconsider. However
> taking a look at a couple of random ones, there are some scripts
> that would benefit from the conversion.

Yes, that is why I said "it is a good idea to do this where
necessary, but the test Dscho touched here does not need it".
It is a given that there are tons of "git config" users as
we have a lot more tests that were written before test_config
was invented.

It is good to occasionally modernise ancient tests; we usually do so
when we need to make some other changes to them (e.g. I added a
feature, and wanted to add a couple of new tests, but I found it
unreadable and unmaintainable because it kept the ancient style, so
I am updating the existing tests to more modern style first before
doing my changes--and then do my changes on top of the cleaned up
codebase).