* Re: [PATCH v8 00/11] Git filter protocol
From: Junio C Hamano @ 2016-09-29 21:27 UTC (permalink / raw)
To: Lars Schneider
Cc: Torsten Bögershausen, git, Jeff King, Stefan Beller,
Jakub Narębski, Martin-Louis Bright, ramsay
In-Reply-To: <1A8A9127-4DF9-44AD-9497-F8A630AB1193@gmail.com>
Lars Schneider <larsxschneider@gmail.com> writes:
> We discussed that issue in v4 and v6:
> http://public-inbox.org/git/20160803225313.pk3tfe5ovz4y3i7l@sigill.intra.peff.net/
> http://public-inbox.org/git/xmqqbn0a3wy3.fsf@gitster.mtv.corp.google.com/
>
> My impression was that you don't want Git to wait for the filter process.
> If Git waits for the filter process - how long should Git wait?
I am not sure where you got that impression. I did say that I do
not want Git to _KILL_ my filter process. That does not mean I want
Git to go away without waiting for me.
If the filter process refuses to die forever when Git told it to
shutdown (by closing the pipe to it, for example), that filter
process is simply buggy. I think we want users to become aware of
that, instead of Git leaving it behind, which essentially is to
sweep the problem under the rug.
I agree with what Peff said elsewhere in the thread; if a filter
process wants to take time to clean things up while letting Git
proceed, it can do its own process management, but I think it is
sensible for Git to wait the filter process it directly spawned.
^ permalink raw reply
* Re: [PATCH v2 01/11] i18n: add--interactive: mark strings for translation
From: Jakub Narębski @ 2016-09-29 21:21 UTC (permalink / raw)
To: Junio C Hamano, Vasco Almeida
Cc: git, Jiang Xin, Ævar Arnfjörð Bjarmason,
David Aguilar
In-Reply-To: <xmqqr387y4le.fsf@gitster.mtv.corp.google.com>
W dniu 26.09.2016 o 00:52, Junio C Hamano pisze:
> Vasco Almeida <vascomalmeida@sapo.pt> writes:
>> my $status_fmt = '%12s %12s %s';
>> -my $status_head = sprintf($status_fmt, 'staged', 'unstaged', 'path');
>> +my $status_head = sprintf($status_fmt, __('staged'), __('unstaged'), __('path'));
>
> Wouldn't it make sense to allow translators to tweak $status_fmt if
> you are allowing the earlier elements that are formatted with %12s,
> as their translation may not fit within that width, in which case
> they may want to make these columns wider?
Perl's printf, sprintf, and format think all codepoints take up 1 print
column; also, without "use utf8;" they all think that one byte is one
codepoint (as it is in latin1 encoding).
Many codepoints can take 0 print columns (zero-width joiners), or 2
columns (so called wide characters).
The proper way to justify Unicode output is described e.g. in
http://www.perl.com/pub/2012/05/perlunicook-unicode-column-width-for-printing.html
use Unicode::GCString;
my $gcs = Unicode::GCString->new($str); # grapheme cluster string
my $cols = $gcs->columns;
my $pad = " " x (12 - $cols);
$status_head .= $str . $pad . " ";
Though we would need to provide fallback if there is no perl-i18n,
no extended Unicode support in Perl (also, if we are not using
gettext).
So it is even more complicated.
>> prompt_yesno(
>> - 'Your edited hunk does not apply. Edit again '
>> - . '(saying "no" discards!) [y/n]? '
>> + # TRANSLATORS: do not translate [y/n]
>> + # The program will only accept that input
>> + # at this point.
>> + __('Your edited hunk does not apply. Edit again '
>> + . '(saying "no" discards!) [y/n]? ')
>
> Not just [y/n], but "no" in "saying no discards!" also needs to
> stay, no? I wonder if it is a good idea to lose the TRANSLATORS
> comment by ejecting "[y/n]" outside the "__()" construct here.
Actually the message to translators should also mention that if
the translation of "no" doesn't begin with 'n', then one needs
to say something like '(saying "n" for "no" discards!)'.
Best,
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH v8 00/11] Git filter protocol
From: Junio C Hamano @ 2016-09-29 21:19 UTC (permalink / raw)
To: Jeff King
Cc: Torsten Bögershausen, Lars Schneider, git, Stefan Beller,
Jakub Narębski, Martin-Louis Bright, ramsay
In-Reply-To: <20160929180247.d4owhzwyawtanw3r@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I don't necessarily agree, though, that the timing of filter-process
> cleanup needs to be part of the public interface. So in your list:
>
>> 3) Git waits until the filter process finishes.
>
> That seems simple and elegant, but I can think of reasons we might not
> want to wait (e.g., if the filter has to do some maintenance task and
> does not the user to have to wait).
>
> OTOH, we already face this in git, and we solve it by explicitly
> backgrounding the maintenance task (i.e., auto-gc). So one could argue
> that it is the responsibility of the filter process to manage its own
> processes. It certainly makes the interaction with git simpler.
Yup, that summarizes my thinking a lot better than I managed to do
in the previous message.
^ permalink raw reply
* Re: [PATCH v8 00/11] Git filter protocol
From: Junio C Hamano @ 2016-09-29 21:17 UTC (permalink / raw)
To: Jakub Narębski
Cc: Torsten Bögershausen, Lars Schneider, git, Jeff King,
Stefan Beller, Martin-Louis Bright, Ramsay Jones
In-Reply-To: <f9a6dd02-34c0-d48b-3cbc-73202488920c@gmail.com>
Jakub Narębski <jnareb@gmail.com> writes:
> Or even better: make filter driver write its pid to pidfile, and then
> "wait $(cat rot13-filter.pid)". That's what we do in lib-git-daemon.sh
> (I think).
I am not sure if "wait"ing on a random process that is not a direct
child is a reasonable thing to do, but I like the direction.
Communicate with a pidfile and wait until "kill -0 $that_pid" fails,
or something like that, would be clean enough.
^ permalink raw reply
* Re: [PATCH v8 00/11] Git filter protocol
From: Junio C Hamano @ 2016-09-29 21:12 UTC (permalink / raw)
To: Lars Schneider
Cc: Torsten Bögershausen, git, Jeff King, Stefan Beller,
Jakub Narębski, Martin-Louis Bright, ramsay
In-Reply-To: <DADB0C80-1EDF-4498-8DAC-A1B09E596518@gmail.com>
Lars Schneider <larsxschneider@gmail.com> writes:
> A pragmatic approach:
>
> I could drop the "STOP" message that the filter writes to the log
> on exit and everything would work as is. We could argue that this
> is OK because Git doesn't care anyways if the filter process has
> stopped or not.
That would mean you can leave the process running while the test
framework tries to remove the trash directory when we are done,
creating the same bug J6t mentioned in the thread, no?
^ permalink raw reply
* Re: [PATCH 2/4] t13xx: do not assume system config is empty
From: Jeff King @ 2016-09-29 21:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, torvalds
In-Reply-To: <xmqqoa36e7v8.fsf@gitster.mtv.corp.google.com>
On Thu, Sep 29, 2016 at 02:03:39PM -0700, Junio C Hamano wrote:
> > - git config --show-origin --get-regexp "user\.[g|l].*" >output &&
> > + git config --show-origin --get-regexp "user\.[g|l|s].*" >output &&
> > test_cmp expect output
> > '
>
> Makes sense modulo you inherited useless vertical bars from the
> original. I'll squash something like that in but without || ;-)
Heh, I glossed over that completely. Thanks.
-Peff
^ permalink raw reply
* Re: [PATCH 2/4] t13xx: do not assume system config is empty
From: Junio C Hamano @ 2016-09-29 21:03 UTC (permalink / raw)
To: Jeff King; +Cc: git, torvalds
In-Reply-To: <20160929192613.o6q2fqp3mjntz2l6@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Good description.
>
> Signed-off-by: Jeff King <peff@peff.net>
>
> of course.
>
>> @@ -1304,6 +1315,7 @@ test_expect_success '--show-origin with --get-regexp' '
>> file:$HOME/.gitconfig user.global true
>> file:.git/config user.local true
>> EOF
>> + GIT_CONFIG_SYSTEM_PATH=$HOME/etc-gitconfig \
>> git config --show-origin --get-regexp "user\.[g|l].*" >output &&
>> test_cmp expect output
>> '
>
> This is one is trying to do a multi-file lookup, but we couldn't look in
> the system config before. But to naturally extend it, it ought to look
> like this on top:
>
> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
> index d2476a8..4dd5ce3 100755
> --- a/t/t1300-repo-config.sh
> +++ b/t/t1300-repo-config.sh
> @@ -1310,11 +1310,12 @@ test_expect_success '--show-origin with single file' '
>
> test_expect_success '--show-origin with --get-regexp' '
> cat >expect <<-EOF &&
> + file:$HOME/etc-gitconfig user.system true
> file:$HOME/.gitconfig user.global true
> file:.git/config user.local true
> EOF
> GIT_ETC_GITCONFIG=$HOME/etc-gitconfig \
> - git config --show-origin --get-regexp "user\.[g|l].*" >output &&
> + git config --show-origin --get-regexp "user\.[g|l|s].*" >output &&
> test_cmp expect output
> '
Makes sense modulo you inherited useless vertical bars from the
original. I'll squash something like that in but without || ;-)
Thanks.
^ permalink raw reply
* [PATCH v2 9/9] core.abbrev: raise the default abbreviation to 12 hexdigits
From: Junio C Hamano @ 2016-09-29 21:00 UTC (permalink / raw)
To: git
In-Reply-To: <20160929210014.3874-1-gitster@pobox.com>
As Peff said, responding in a thread started by Linus's suggestion
to raise the default abbreviation to 12 hexdigits:
I actually think "12" might be sane for a long time. That's 48
bits of sha1, so we'd expect a 50% chance of a single collision
at 2^24, or 16 million. The biggest repository I know about (in
number of objects) is the one holding all of the objects for all
of the forks of torvalds/linux on GitHub. It's at about 15
million objects.
Which seems close, but remember that's the size where we expect
to see a single collision. They don't become common until much
later (I didn't compute an exact number, but Linus's 16x sounds
about right). I know that the growth of the kernel isn't really
linear, but I think the need to bump to "13" might not just be
decades, but possibly a century or more.
So 12 seems reasonable, and the only downside for it (or for "13", for
that matter) is a few extra bytes. I dunno, maybe people will really
hate that, but I have a feeling these are mostly cut-and-pasted anyway.
And this does exactly that.
Keep the tests working by explicitly asking for the old 7 hexdigits
setting in the fake system-wide configuration file used for tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
environment.c | 2 +-
t/gitconfig-for-test | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/environment.c b/environment.c
index ca72464a9850..25daddbc13d6 100644
--- a/environment.c
+++ b/environment.c
@@ -16,7 +16,7 @@ int trust_executable_bit = 1;
int trust_ctime = 1;
int check_stat = 1;
int has_symlinks = 1;
-int minimum_abbrev = 4, default_abbrev = 7;
+int minimum_abbrev = 4, default_abbrev = 12;
int ignore_case;
int assume_unchanged;
int prefer_symlink_refs;
diff --git a/t/gitconfig-for-test b/t/gitconfig-for-test
index 4598885ed5c3..8c284425d725 100644
--- a/t/gitconfig-for-test
+++ b/t/gitconfig-for-test
@@ -4,3 +4,6 @@
;; [user]
;; name = A U Thor
;; email = author@example.com
+
+[core]
+ abbrev = 7
--
2.10.0-589-g5adf4e1
^ permalink raw reply related
* [PATCH v2 8/9] worktree: honor configuration variables
From: Junio C Hamano @ 2016-09-29 21:00 UTC (permalink / raw)
To: git
In-Reply-To: <20160929210014.3874-1-gitster@pobox.com>
The command accesses default_abbrev (defined in environment.c and is
updated via core.abbrev configuration), but never makes any call to
git_config(). The output from "worktree list" ignores the abbrev
setting for this reason.
Make a call to git_config() to read the default set of configuration
variables at the beginning of the command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/worktree.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 6dcf7bd9d270..5c4854d3e4a6 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -528,6 +528,8 @@ int cmd_worktree(int ac, const char **av, const char *prefix)
OPT_END()
};
+ git_config(git_default_config, NULL);
+
if (ac < 2)
usage_with_options(worktree_usage, options);
if (!prefix)
--
2.10.0-589-g5adf4e1
^ permalink raw reply related
* [PATCH v2 7/9] t1300: be explicit in local configuration tests
From: Junio C Hamano @ 2016-09-29 21:00 UTC (permalink / raw)
To: git
In-Reply-To: <20160929210014.3874-1-gitster@pobox.com>
Many tests in this script prepare variable settings in the
repository local configuration and expects "--list" to report only
the ones from the repository local configuration.
This happened to work while we were running out tests under
GIT_CONFIG_NOSYSTEM and/or with an empty system-wide configuration
file, but as we will soon make our fake system-wide configuration
non-empty, prepare for that change by explicitly telling the command
to look only at "--local" configuration.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t1300-repo-config.sh | 80 +++++++++++++++++++++++++-------------------------
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 2a15cd4d150d..8979212946c0 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -245,18 +245,18 @@ test_expect_success 'multivar' '
'
test_expect_success 'non-match' '
- git config --get nextsection.nonewline !for
+ git config --local --get nextsection.nonewline !for
'
test_expect_success 'non-match value' '
echo wow >expect &&
- git config --get nextsection.nonewline !for >actual &&
+ git config --local --get nextsection.nonewline !for >actual &&
test_cmp expect actual
'
test_expect_success 'multi-valued get returns final one' '
echo "wow2 for me" >expect &&
- git config --get nextsection.nonewline >actual &&
+ git config --local --get nextsection.nonewline >actual &&
test_cmp expect actual
'
@@ -265,7 +265,7 @@ test_expect_success 'multi-valued get-all returns all' '
wow
wow2 for me
EOF
- git config --get-all nextsection.nonewline >actual &&
+ git config --local --get-all nextsection.nonewline >actual &&
test_cmp expect actual
'
@@ -341,7 +341,7 @@ version.1.2.3eX.alpha=beta
EOF
test_expect_success 'working --list' '
- git config --list > output &&
+ git config --local --list > output &&
test_cmp expect output
'
@@ -361,7 +361,7 @@ version.1.2.3eX.alpha
EOF
test_expect_success '--name-only --list' '
- git config --name-only --list >output &&
+ git config --local --name-only --list >output &&
test_cmp expect output
'
@@ -371,7 +371,7 @@ nextsection.nonewline wow2 for me
EOF
test_expect_success '--get-regexp' '
- git config --get-regexp in >output &&
+ git config --local --get-regexp in >output &&
test_cmp expect output
'
@@ -381,7 +381,7 @@ nextsection.nonewline
EOF
test_expect_success '--name-only --get-regexp' '
- git config --name-only --get-regexp in >output &&
+ git config --local --name-only --get-regexp in >output &&
test_cmp expect output
'
@@ -392,7 +392,7 @@ EOF
test_expect_success '--add' '
git config --add nextsection.nonewline "wow4 for you" &&
- git config --get-all nextsection.nonewline > output &&
+ git config --local --get-all nextsection.nonewline > output &&
test_cmp expect output
'
@@ -404,45 +404,45 @@ cat > .git/config << EOF
EOF
test_expect_success 'get variable with no value' '
- git config --get novalue.variable ^$
+ git config --local --get novalue.variable ^$
'
test_expect_success 'get variable with empty value' '
- git config --get emptyvalue.variable ^$
+ git config --local --get emptyvalue.variable ^$
'
echo novalue.variable > expect
test_expect_success 'get-regexp variable with no value' '
- git config --get-regexp novalue > output &&
+ git config --local --get-regexp novalue > output &&
test_cmp expect output
'
echo 'novalue.variable true' > expect
test_expect_success 'get-regexp --bool variable with no value' '
- git config --bool --get-regexp novalue > output &&
+ git config --local --bool --get-regexp novalue > output &&
test_cmp expect output
'
echo 'emptyvalue.variable ' > expect
test_expect_success 'get-regexp variable with empty value' '
- git config --get-regexp emptyvalue > output &&
+ git config --local --get-regexp emptyvalue > output &&
test_cmp expect output
'
echo true > expect
test_expect_success 'get bool variable with no value' '
- git config --bool novalue.variable > output &&
+ git config --local --bool novalue.variable > output &&
test_cmp expect output
'
echo false > expect
test_expect_success 'get bool variable with empty value' '
- git config --bool emptyvalue.variable > output &&
+ git config --local --bool emptyvalue.variable > output &&
test_cmp expect output
'
@@ -683,15 +683,15 @@ test_expect_success numbers '
git config mega.ton 1m &&
echo 1024 >expect &&
echo 1048576 >>expect &&
- git config --int --get kilo.gram >actual &&
- git config --int --get mega.ton >>actual &&
+ git config --local --int --get kilo.gram >actual &&
+ git config --local --int --get mega.ton >>actual &&
test_cmp expect actual
'
test_expect_success '--int is at least 64 bits' '
git config giga.watts 121g &&
echo 129922760704 >expect &&
- git config --int --get giga.watts >actual &&
+ git config --local --int --get giga.watts >actual &&
test_cmp expect actual
'
@@ -700,7 +700,7 @@ test_expect_success 'invalid unit' '
echo 1auto >expect &&
git config aninvalid.unit >actual &&
test_cmp expect actual &&
- test_must_fail git config --int --get aninvalid.unit 2>actual &&
+ test_must_fail git config --local --int --get aninvalid.unit 2>actual &&
test_i18ngrep "bad numeric config value .1auto. for .aninvalid.unit. in file .git/config: invalid unit" actual
'
@@ -733,15 +733,15 @@ test_expect_success bool '
rm -f result &&
for i in 1 2 3 4
do
- git config --bool --get bool.true$i >>result
- git config --bool --get bool.false$i >>result
+ git config --local --bool --get bool.true$i >>result
+ git config --local --bool --get bool.false$i >>result
done &&
test_cmp expect result'
test_expect_success 'invalid bool (--get)' '
git config bool.nobool foobar &&
- test_must_fail git config --bool --get bool.nobool'
+ test_must_fail git config --local --bool --get bool.nobool'
test_expect_success 'invalid bool (set)' '
@@ -808,12 +808,12 @@ test_expect_success 'get --bool-or-int' '
-1
EOF
{
- git config --bool-or-int bool.true1 &&
- git config --bool-or-int bool.true2 &&
- git config --bool-or-int bool.false &&
- git config --bool-or-int int.int1 &&
- git config --bool-or-int int.int2 &&
- git config --bool-or-int int.int3
+ git config --local --bool-or-int bool.true1 &&
+ git config --local --bool-or-int bool.true2 &&
+ git config --local --bool-or-int bool.false &&
+ git config --local --bool-or-int int.int1 &&
+ git config --local --bool-or-int int.int2 &&
+ git config --local --bool-or-int int.int3
} >actual &&
test_cmp expect actual
'
@@ -868,9 +868,9 @@ foo~
EOF
test_expect_success HOMEVAR 'get --path' '
- git config --get --path path.home > result &&
- git config --get --path path.normal >> result &&
- git config --get --path path.trailingtilde >> result &&
+ git config --local --get --path path.home > result &&
+ git config --local --get --path path.normal >> result &&
+ git config --local --get --path path.trailingtilde >> result &&
test_cmp expect result
'
@@ -882,10 +882,10 @@ EOF
test_expect_success !MINGW 'get --path copes with unset $HOME' '
(
unset HOME;
- test_must_fail git config --get --path path.home \
+ test_must_fail git config --local --get --path path.home \
>result 2>msg &&
- git config --get --path path.normal >>result &&
- git config --get --path path.trailingtilde >>result
+ git config --local --get --path path.normal >>result &&
+ git config --local --get --path path.trailingtilde >>result
) &&
test_i18ngrep "[Ff]ailed to expand.*~/" msg &&
test_cmp expect result
@@ -893,7 +893,7 @@ test_expect_success !MINGW 'get --path copes with unset $HOME' '
test_expect_success 'get --path barfs on boolean variable' '
echo "[path]bool" >.git/config &&
- test_must_fail git config --get --path path.bool
+ test_must_fail git config --local --get --path path.bool
'
cat > expect << EOF
@@ -936,7 +936,7 @@ section.quotecont=cont;inued
EOF
test_expect_success 'value continued on next line' '
- git config --list > result &&
+ git config --local --list > result &&
test_cmp expect result
'
@@ -960,14 +960,14 @@ Qsection.sub=section.val4
Qsection.sub=section.val5Q
EOF
test_expect_success '--null --list' '
- git config --null --list >result.raw &&
+ git config --local --null --list >result.raw &&
nul_to_q <result.raw >result &&
echo >>result &&
test_cmp expect result
'
test_expect_success '--null --get-regexp' '
- git config --null --get-regexp "val[0-9]" >result.raw &&
+ git config --local --null --get-regexp "val[0-9]" >result.raw &&
nul_to_q <result.raw >result &&
echo >>result &&
test_cmp expect result
@@ -1127,7 +1127,7 @@ test_expect_success 'barf on syntax error' '
[section]
key garbage
EOF
- test_must_fail git config --get section.key >actual 2>error &&
+ test_must_fail git config --local --get section.key >actual 2>error &&
test_i18ngrep " line 3 " error
'
--
2.10.0-589-g5adf4e1
^ permalink raw reply related
* [PATCH v2 6/9] t1300: take contents of system-wide configuration into account in "--list" test
From: Junio C Hamano @ 2016-09-29 21:00 UTC (permalink / raw)
To: git
In-Reply-To: <20160929210014.3874-1-gitster@pobox.com>
One of the "git config" test tries to see that the command run
without a valid repository still shows non-repository specific
configuration. As we are planning to later make the system-wide
file non-empty, prepare for the change by expecting to see the
contents from it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t1300-repo-config.sh | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 95734034e0d5..2a15cd4d150d 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -344,10 +344,11 @@ test_expect_success 'working --list' '
git config --list > output &&
test_cmp expect output
'
-cat > expect << EOF
-EOF
-test_expect_success '--list without repo produces empty output' '
+test_expect_success '--list without repo shows only system-wide and global' '
+ # The global one aka $HOME/.gitconfig is missing,
+ # so we do not have to worry about it.
+ git config --system --list >expect &&
git --git-dir=nonexistent config --list >output &&
test_cmp expect output
'
--
2.10.0-589-g5adf4e1
^ permalink raw reply related
* [PATCH v2 5/9] t1300: disable system-wide config for tests that wants to read from -c
From: Junio C Hamano @ 2016-09-29 21:00 UTC (permalink / raw)
To: git
In-Reply-To: <20160929210014.3874-1-gitster@pobox.com>
This test wants to do
git -c x.two=2 config --get-regexp ^x\.*
and see x.two that came from the one-shot configuration in its
output. This form cannot be limited with "--local", as it limits
the input to the local configuration file and makes these one-shot
settings ignored. At this point, the test knows that there is no
variable that match x.* in its local configuration, and it also was
OK to assume that there is nothing in the system-wide config or
global one.
Make sure that assumption holds by using the GIT_CONFIG_NOSYSTEM
environment, as we may add anything to t/gitconfig-for-test later.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t1300-repo-config.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 940469339bd2..95734034e0d5 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1093,6 +1093,7 @@ test_expect_success 'multiple git -c appends config' '
x.one 1
x.two 2
EOF
+ GIT_CONFIG_NOSYSTEM=1 \
git -c x.one=1 x >actual &&
test_cmp expect actual
'
--
2.10.0-589-g5adf4e1
^ permalink raw reply related
* [PATCH v2 4/9] t1300: check also system-wide configuration file in --show-origin tests
From: Junio C Hamano @ 2016-09-29 21:00 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20160929210014.3874-1-gitster@pobox.com>
From: Jeff King <peff@peff.net>
Because we used to run our tests with GIT_CONFIG_NOSYSTEM, these did
not test that the system-wide configuration file is also read and
shown as one of the origins. Create a custom/fake system-wide
configuration file and make sure it appears in the output, using the
newly introduced GIT_CONFIG_SYSTEM_PATH mechanism.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t1300-repo-config.sh | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 1b3f6f4854f9..940469339bd2 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1236,6 +1236,11 @@ test_expect_success 'set up --show-origin tests' '
[user]
relative = include
EOF
+ cat >"$HOME"/etc-gitconfig <<-\EOF &&
+ [user]
+ system = true
+ override = system
+ EOF
cat >"$HOME"/.gitconfig <<-EOF &&
[user]
global = true
@@ -1254,6 +1259,8 @@ test_expect_success 'set up --show-origin tests' '
test_expect_success '--show-origin with --list' '
cat >expect <<-EOF &&
+ file:$HOME/etc-gitconfig user.system=true
+ file:$HOME/etc-gitconfig user.override=system
file:$HOME/.gitconfig user.global=true
file:$HOME/.gitconfig user.override=global
file:$HOME/.gitconfig include.path=$INCLUDE_DIR/absolute.include
@@ -1264,13 +1271,16 @@ test_expect_success '--show-origin with --list' '
file:.git/../include/relative.include user.relative=include
command line: user.cmdline=true
EOF
+ GIT_CONFIG_SYSTEM_PATH=$HOME/etc-gitconfig \
git -c user.cmdline=true config --list --show-origin >output &&
test_cmp expect output
'
test_expect_success '--show-origin with --list --null' '
cat >expect <<-EOF &&
- file:$HOME/.gitconfigQuser.global
+ file:$HOME/etc-gitconfigQuser.system
+ trueQfile:$HOME/etc-gitconfigQuser.override
+ systemQfile:$HOME/.gitconfigQuser.global
trueQfile:$HOME/.gitconfigQuser.override
globalQfile:$HOME/.gitconfigQinclude.path
$INCLUDE_DIR/absolute.includeQfile:$INCLUDE_DIR/absolute.includeQuser.absolute
@@ -1281,6 +1291,7 @@ test_expect_success '--show-origin with --list --null' '
includeQcommand line:Quser.cmdline
trueQ
EOF
+ GIT_CONFIG_SYSTEM_PATH=$HOME/etc-gitconfig \
git -c user.cmdline=true config --null --list --show-origin >output.raw &&
nul_to_q <output.raw >output &&
# The here-doc above adds a newline that the --null output would not
@@ -1304,6 +1315,7 @@ test_expect_success '--show-origin with --get-regexp' '
file:$HOME/.gitconfig user.global true
file:.git/config user.local true
EOF
+ GIT_CONFIG_SYSTEM_PATH=$HOME/etc-gitconfig \
git config --show-origin --get-regexp "user\.[g|l].*" >output &&
test_cmp expect output
'
@@ -1312,6 +1324,7 @@ test_expect_success '--show-origin getting a single key' '
cat >expect <<-\EOF &&
file:.git/config local
EOF
+ GIT_CONFIG_SYSTEM_PATH=$HOME/etc-gitconfig \
git config --show-origin user.override >output &&
test_cmp expect output
'
--
2.10.0-589-g5adf4e1
^ permalink raw reply related
* [PATCH v2 3/9] t1308: ignore system-wide config in the iteration test
From: Junio C Hamano @ 2016-09-29 21:00 UTC (permalink / raw)
To: git
In-Reply-To: <20160929210014.3874-1-gitster@pobox.com>
We do not want to keep track of the exact contents of the fake
system-wide t/gitconfig-for-test configuration file. Keep ignoring
it as we used to.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t1308-config-set.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t1308-config-set.sh b/t/t1308-config-set.sh
index 7655c94c2801..5d5adb1efd8e 100755
--- a/t/t1308-config-set.sh
+++ b/t/t1308-config-set.sh
@@ -260,6 +260,7 @@ test_expect_success 'iteration shows correct origins' '
name=
scope=cmdline
EOF
+ GIT_CONFIG_NOSYSTEM=1 \
GIT_CONFIG_PARAMETERS=$cmdline_config test-config iterate >actual &&
test_cmp expect actual
'
--
2.10.0-589-g5adf4e1
^ permalink raw reply related
* [PATCH v2 2/9] t1300: always compare expect to actual
From: Junio C Hamano @ 2016-09-29 21:00 UTC (permalink / raw)
To: git
In-Reply-To: <20160929210014.3874-1-gitster@pobox.com>
The two arguments to the test_cmp helper should always have the
expected output first and then the actual one, so that an unmet
expectation would appear as
-what we wanted to see
+what we actually saw
in its output.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t1300-repo-config.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 0543b62227bf..1b3f6f4854f9 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -936,7 +936,7 @@ EOF
test_expect_success 'value continued on next line' '
git config --list > result &&
- test_cmp result expect
+ test_cmp expect result
'
cat > .git/config <<\EOF
--
2.10.0-589-g5adf4e1
^ permalink raw reply related
* [PATCH v2 1/9] config: allow customizing /etc/gitconfig location with an environment
From: Junio C Hamano @ 2016-09-29 21:00 UTC (permalink / raw)
To: git
In-Reply-To: <20160929210014.3874-1-gitster@pobox.com>
We introduced GIT_CONFIG_NOSYSTEM environment variable at ab88c363
("allow suppressing of global and system config", 2008-02-06),
primarily to protect our tests from random set of configuration
variables the system administrators would put in /etc/gitconfig
file.
Introduce a new environment variable GIT_CONFIG_SYSTEM_PATH, and allow
the users to specify a file that is used instead of /etc/gitconfig
to read (and write) the system-wide configuration. By doing so, we
can force our tests to honor certain configuration settings by
default by pointing GIT_CONFIG_SYSTEM_PATH at our own, in addition to the
existing GIT_CONFIG_NOSYSTEM mechanism.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
cache.h | 1 +
config.c | 2 ++
t/gitconfig-for-test | 6 ++++++
t/t1300-repo-config.sh | 15 +++++++++++++++
t/test-lib.sh | 4 ++--
5 files changed, 26 insertions(+), 2 deletions(-)
create mode 100644 t/gitconfig-for-test
diff --git a/cache.h b/cache.h
index b0dae4bac1a1..d4b689f386d6 100644
--- a/cache.h
+++ b/cache.h
@@ -408,6 +408,7 @@ static inline enum object_type object_type(unsigned int mode)
#define GIT_NAMESPACE_ENVIRONMENT "GIT_NAMESPACE"
#define GIT_WORK_TREE_ENVIRONMENT "GIT_WORK_TREE"
#define GIT_PREFIX_ENVIRONMENT "GIT_PREFIX"
+#define GIT_CONFIG_SYSTEM_PATH_ENVIRONMENT "GIT_CONFIG_SYSTEM_PATH"
#define DEFAULT_GIT_DIR_ENVIRONMENT ".git"
#define DB_ENVIRONMENT "GIT_OBJECT_DIRECTORY"
#define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
diff --git a/config.c b/config.c
index 0dfed682b868..096bb754aad7 100644
--- a/config.c
+++ b/config.c
@@ -1253,6 +1253,8 @@ const char *git_etc_gitconfig(void)
{
static const char *system_wide;
if (!system_wide)
+ system_wide = getenv(GIT_CONFIG_SYSTEM_PATH_ENVIRONMENT);
+ if (!system_wide)
system_wide = system_path(ETC_GITCONFIG);
return system_wide;
}
diff --git a/t/gitconfig-for-test b/t/gitconfig-for-test
new file mode 100644
index 000000000000..4598885ed5c3
--- /dev/null
+++ b/t/gitconfig-for-test
@@ -0,0 +1,6 @@
+;; This file is used as if it were /etc/gitconfig while running the
+;; test scripts in this directory.
+;;
+;; [user]
+;; name = A U Thor
+;; email = author@example.com
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 923bfc5a2606..0543b62227bf 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1372,4 +1372,19 @@ test_expect_success !MINGW '--show-origin blob ref' '
test_cmp expect output
'
+test_expect_success 'system-wide configuration' '
+ system="$TRASH_DIRECTORY/system-wide" &&
+ >"$system" &&
+ git config -f "$system" --add frotz.nitfol xyzzy &&
+
+ git config -f "$system" frotz.nitfol >expect &&
+ GIT_CONFIG_SYSTEM_PATH="$system" \
+ git config --system frotz.nitfol >actual &&
+
+ GIT_CONFIG_SYSTEM_PATH="$system" \
+ git config --system --replace-all frotz.nitfol blorb &&
+ echo blorb >expect &&
+ GIT_CONFIG_SYSTEM_PATH="$system" git config --system frotz.nitfol >actual
+'
+
test_done
diff --git a/t/test-lib.sh b/t/test-lib.sh
index ac56512a1c5e..b811e4c70273 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -851,9 +851,9 @@ else # normal case, use ../bin-wrappers only unless $with_dashes:
fi
fi
GIT_TEMPLATE_DIR="$GIT_BUILD_DIR"/templates/blt
-GIT_CONFIG_NOSYSTEM=1
+GIT_CONFIG_SYSTEM_PATH="$GIT_BUILD_DIR/t/gitconfig-for-test"
GIT_ATTR_NOSYSTEM=1
-export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG_NOSYSTEM GIT_ATTR_NOSYSTEM
+export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG_SYSTEM_PATH GIT_ATTR_NOSYSTEM
if test -z "$GIT_TEST_CMP"
then
--
2.10.0-589-g5adf4e1
^ permalink raw reply related
* [PATCH v2 0/9] allow customizing /etc/gitconfig location with an environment
From: Junio C Hamano @ 2016-09-29 21:00 UTC (permalink / raw)
To: git
This ended up growing quite a bit, and I mostly hate it.
- Patch 1 introduces GIT_CONFIG_SYSTEM_PATH environment variable
that lets you point at a file other than /etc/gitconfig to
pretend that your file is the system-wide configuration.
- Patch 2 is a small bugfix.
- Patches 3-7 are updates to 1300 and 1308, i.e. tests for "git
config", to make them more robust, in preparation for using
GIT_CONFIG_SYSTEM_PATH mechanism to point at a file during the
test. It protects them a bit more than necessary in that the
variables some of the tests they use when they try to see the
output from "git config --get" are unlikely to appear in the fake
system-wide configuration during the test (hence disabling the
fake system-wide configuration has no practical effect), but
nevertheless the calls are protected by explicitly telling them
to read only from --local configuration file to future-proof
them.
- Patch 8 is queued elsewhere already.
- Patch 9 raises the default core.abbrev to 12 and countermands it
by setting it to 7 in a fake system-wide configuration file
during our test. The unconditional widening of the default
abbreviation size in this patch will have to be discarded,
preferring the approach Linus is taking to auto-size it based on
the number of objects in the repository, but the part that
updates the test script may still be necessary.
Jeff King (1):
t1300: check also system-wide configuration file in --show-origin
tests
Junio C Hamano (8):
config: allow customizing /etc/gitconfig location with an environment
t1300: always compare expect to actual
t1308: ignore system-wide config in the iteration test
t1300: disable system-wide config for tests that wants to read from -c
t1300: take contents of system-wide configuration into account in
"--list" test
t1300: be explicit in local configuration tests
worktree: honor configuration variables
core.abbrev: raise the default abbreviation to 12 hexdigits
builtin/worktree.c | 2 +
cache.h | 1 +
config.c | 2 +
environment.c | 2 +-
t/gitconfig-for-test | 9 ++++
t/t1300-repo-config.sh | 120 ++++++++++++++++++++++++++++++-------------------
t/t1308-config-set.sh | 1 +
t/test-lib.sh | 4 +-
8 files changed, 93 insertions(+), 48 deletions(-)
create mode 100644 t/gitconfig-for-test
--
2.10.0-589-g5adf4e1
^ permalink raw reply
* Re: [PATCH v8 00/11] Git filter protocol
From: Jakub Narębski @ 2016-09-29 20:59 UTC (permalink / raw)
To: Torsten Bögershausen, Lars Schneider, Junio C Hamano
Cc: git, Jeff King, Stefan Beller, Martin-Louis Bright, Ramsay Jones
In-Reply-To: <f7a4f828-bb1d-0ffa-e369-3b4fa476d9e5@web.de>
W dniu 29.09.2016 o 13:57, Torsten Bögershausen pisze:
> On 29/09/16 12:28, Lars Schneider wrote:
>> This is what happens:
>>
>> 1) Git exits
>> 2) The filter process receives EOF and prints "STOP" to the log
>> 3) t0021 checks the content of the log
>>
>> Sometimes 3 happened before 2 which makes the test fail.
>> (Example: https://travis-ci.org/git/git/jobs/162660563 )
>>
>> I added a this to wait until the filter process terminates:
>>
>> +wait_for_filter_termination () {
>> + while ps | grep -v grep | grep -F "/t0021/rot13-filter.pl" >/dev/null 2>&1
>> + do
>> + echo "Waiting for /t0021/rot13-filter.pl to finish..."
>> + sleep 1
>> + done
>> +}
>>
>> Does this look OK to you?
> Do we need the ps at all ?
> How about this:
>
> +wait_for_filter_termination () {
> + while ! grep "STOP" LOGFILENAME >/dev/null
> + do
> + echo "Waiting for /t0021/rot13-filter.pl to finish..."
> + sleep 1
> + done
> +}
Or even better: make filter driver write its pid to pidfile, and then
"wait $(cat rot13-filter.pid)". That's what we do in lib-git-daemon.sh
(I think).
If the problem is exit status of "wait" builtin, then filter driver
can remove its pidfile after writing "STOP", just before ending.
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH v8 00/11] Git filter protocol
From: Lars Schneider @ 2016-09-29 20:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Torsten Bögershausen, git, Jeff King, Stefan Beller,
Jakub Narębski, Martin-Louis Bright, ramsay
In-Reply-To: <xmqqk2duhcdm.fsf@gitster.mtv.corp.google.com>
> On 29 Sep 2016, at 18:57, Junio C Hamano <gitster@pobox.com> wrote:
>
> Torsten Bögershausen <tboegi@web.de> writes:
>
>>> 1) Git exits
>>> 2) The filter process receives EOF and prints "STOP" to the log
>>> 3) t0021 checks the content of the log
>>>
>>> Sometimes 3 happened before 2 which makes the test fail.
>>> (Example: https://travis-ci.org/git/git/jobs/162660563 )
>>>
>>> I added a this to wait until the filter process terminates:
>>>
>>> +wait_for_filter_termination () {
>>> + while ps | grep -v grep | grep -F "/t0021/rot13-filter.pl" >/dev/null 2>&1
>>> + do
>>> + echo "Waiting for /t0021/rot13-filter.pl to finish..."
>>> + sleep 1
>>> + done
>>> +}
>>>
>>> Does this look OK to you?
>> Do we need the ps at all ?
>> How about this:
>>
>> +wait_for_filter_termination () {
>> + while ! grep "STOP" LOGFILENAME >/dev/null
>> + do
>> + echo "Waiting for /t0021/rot13-filter.pl to finish..."
>> + sleep 1
>> + done
>> +}
>
> Running "ps" and grepping for a command is not suitable for script
> to reliably tell things, so it is out of question. Compared to
> that, your version looks slightly better, but what if the machinery
> that being tested, i.e. the part that drives the filter process, is
> buggy or becomes buggy and causes the filter process that writes
> "STOP" to die before it actually writes that string?
>
> I have a feeling that the machinery being tested needs to be fixed
> so that the sequence is always be:
>
> 0) Git spawns the filter process, as it needs some contents to
> be filtered.
>
> 1) Git did everything it needed to do and decides that is time
> to go.
>
> 2) Filter process receives EOF and prints "STOP" to the log.
>
> 3) Git waits until the filter process finishes.
>
> 4) t0021, after Git finishes, checks the log.
A pragmatic approach:
I could drop the "STOP" message that the filter writes to the log
on exit and everything would work as is. We could argue that this
is OK because Git doesn't care anyways if the filter process has
stopped or not.
Would that be OK for everyone?
- Lars
^ permalink raw reply
* Re: [PATCH 2/4] t13xx: do not assume system config is empty
From: Junio C Hamano @ 2016-09-29 19:57 UTC (permalink / raw)
To: Jeff King; +Cc: git, torvalds
In-Reply-To: <20160929191857.lxcgzf2cg5zfjkrq@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I just don't see it being a problem. Adding core.abbrev for the whole
> test suite is just about not having a big flag day where we change all
> the tests. Changing one or two tests (and again, I'd be surprised if we
> even have to do that) doesn't seem like a big deal.
I've already wasted several hours whipping t1300 into shape, because
it was done in not so forward-looking future-proofed way. I am not
worried about core.abbrev but I am worried more about the next thing
that requires us to add an entry to t/gitconfig-for-test. Adding a
corresponding entry to retain the old default for that new config to
two places may not be a big deal, but it still makes me feel a bit
uneasy.
In any case, I suspect that Linus's "auto" thing may still need the
custom system config with t1300 clean-up to pass the test, even
though I suspect it would compute that 7 is enough for most of the
tiny repositories our tests use, so I'll polish this a bit more
while waiting for that discussion to settle.
Thanks.
^ permalink raw reply
* Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits
From: Junio C Hamano @ 2016-09-29 19:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Johannes Sixt, Git Mailing List
In-Reply-To: <CA+55aFxNVbvyERNc_xEhrtfTVMGz3hkeAx1nv9vW+dhJwCpp6g@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But you could easily also just instead have it do something like
>
> if (default_abbrev < 0)
> default_abbrev = initialize_abbrev();
>
> at startup time if "abbrev_commit" is set, and just do it once and for
> all rather rthan the odd loping behavior.
I think that is a reasonable way to go.
#define DEFAULT_ABBREV get_default_abbrev()
would help.
^ permalink raw reply
* Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits
From: Junio C Hamano @ 2016-09-29 19:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Sixt, Git Mailing List, Jeff King
In-Reply-To: <CA+55aFx9Utm9yDZceks+5q9c8ydc2QMYshWwJ0G0GHWWLwSsXQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, Sep 29, 2016 at 11:55 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> For the kernel, just the *math* right now actually gives 12
>> characters. For current git it actually seems to say that 8 is the
>> correct number. For small projects, you'll still see 7.
>
> Sorry, the git number is 9, not 8. The reason is that git has roughly
> 212k objects, and 9 hex digits gets expected collisions at about 256k
> objects.
>
> So the logic means that we'll see 7 hex digits for projects with less
> than 16k objects, 8 hex digits if there are less than 64k objects, and
> 9 hex digits for projects like git that currently have fewer than 256k
> objects.
Whew. I was wondering where my brain went wrong, as I knew we have
200k objects and 8 hexdigits means 1<<16 = 64k which is way too
short.
^ permalink raw reply
* Re: [PATCH 4/4] core.abbrev: raise the default abbreviation to 12 hexdigits
From: Linus Torvalds @ 2016-09-29 19:40 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Sixt, Git Mailing List
In-Reply-To: <20160929191609.maxggcli76472t4g@sigill.intra.peff.net>
On Thu, Sep 29, 2016 at 12:16 PM, Jeff King <peff@peff.net> wrote:
>
> Hmm. So at length 7, we expect collisions at 2^14, which is 16384. That
> seems really low. I mean, by the birthday paradox that's where expect
> a 50% chance of a collision. But that's a single collision. We
> definitely don't expect them to be common at that size.
>
> So I suspect this could be a bit looser.
So I have to admit that I was surprised by how quickly it actually
decided that 7 isn't enough. In fact, the reason I initially said that
git used 8 digits was that I didn't count very closely, and just
verified that it was more than the default 7.
But quite frankly, I think the math is correct, and part of that is
that the logic is all about not just the current state, but the
"reasonably near future".
So it is indeed fairly aggressive, and the moment you have more
objects than the "we'd expect to probably see _one_ collision" it
grows the size. But looking at the kernel situation, that really is
what we'd want, because the whole problem with the existing code is
that it only takes the *current* situation into account. That's what
we want to get away from. We want git to pick a number that is sane
from a standpoint of "this project is still growing".
And git _already_ has commits that are ambiguous in 8 hex digits and
need 9. Yes, it's rare today, but the reason I'm telling kernel
developers to use 12 is because while a size-11 collision is very rare
today, it does actually happen, and we want o pick a value where it is
rare enough that even in the near future it's not going to be a big
deal.
Don't get me wrong: collisions aren't fatal. So it's not like we have
to absolutely avoid them, and I really like your patch series exactly
because it makes collisions even less of a deal (particularly since I
expect people will not upgrade immediately, so we'll continue to see
even new 7-hex-digit short forms even in the kernel). So it's a
balance of making the hex string long enough that it's simply not a
big worry.
So I'm sure it *could* be looser, but I actually also really suspect
that git truly *should* use a 9-digit abbreviation rather than 8 (and
7 is definitely starting to be borderline, I think).
> As far as the implementation, I was surprised to see it touch
> get_short_sha1() at all. That's, after all, for lookups, and we would
> never want to require more characters on the reading side.
Heh. The implementation is crap. It was literally a "how can I make
the smallest possible patch" implementation. I was finishing it off
while at a talk by Nicolas Pitre at Linaro Connect where I am right
now.
So I agree - it does extra work just because that's where it all
slotted in with minimal effort.
At a minimum, once it finds a good new default, it should just memoize
that. So a minimal fix to the "it's stupldly recalculating things over
rand over again" would be to just set "default_abbrev" to the value it
finds acceptable after the first time it finds something, so that it
doesn't end up looping _again_ in the future.
But you could easily also just instead have it do something like
if (default_abbrev < 0)
default_abbrev = initialize_abbrev();
at startup time if "abbrev_commit" is set, and just do it once and for
all rather rthan the odd loping behavior.
I really just wanted to see how well the concept worked, and I was
happy to see that it gave what I thought were the "correct" numbers.
And the loop was salready there ...
Linus
^ permalink raw reply
* Impossible to change working directory
From: Sebastian Feldmann @ 2016-09-29 19:30 UTC (permalink / raw)
To: git
Hi there,
I have a problem executing a pre-commit hook.
The hook script has to change the working directory to work and if I use plain
git commit
it works as expected, the script executes without errors, but if I use
git commit —only file.x file.y
the script fails because changing the current working directory fails.
If I echo the current working directory it always echoes the root repository path
Is this expected behavior?
Thanks for your feedback.
Cheers Sebastian
^ permalink raw reply
* Re: [PATCH 2/4] t13xx: do not assume system config is empty
From: Jeff King @ 2016-09-29 19:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, torvalds
In-Reply-To: <xmqq60pefrvc.fsf@gitster.mtv.corp.google.com>
On Thu, Sep 29, 2016 at 12:06:15PM -0700, Junio C Hamano wrote:
> I think it deserves a separate patch and the result is more
> understandable. I've queued this for now (on top of a revised 1/4
> that uses GIT_CONFIG_SYSTEM_PATH instead).
Thanks, makes sense (and I like the new variable name better, by the
way).
> -- >8 --
> From: Jeff King <peff@peff.net>
> Date: Thu, 29 Sep 2016 11:29:10 -0700
> Subject: [PATCH] t1300: check also system-wide configuration file in
> --show-origin tests
>
> Because we used to run our tests with GIT_CONFIG_NOSYSTEM, these did
> not test that the system-wide configuration file is also read and
> shown as one of the origins. Create a custom/fake system-wide
> configuration file and make sure it appears in the output, using the
> newly introduced GIT_CONFIG_SYSTEM_PATH mechanism.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Good description.
Signed-off-by: Jeff King <peff@peff.net>
of course.
> @@ -1304,6 +1315,7 @@ test_expect_success '--show-origin with --get-regexp' '
> file:$HOME/.gitconfig user.global true
> file:.git/config user.local true
> EOF
> + GIT_CONFIG_SYSTEM_PATH=$HOME/etc-gitconfig \
> git config --show-origin --get-regexp "user\.[g|l].*" >output &&
> test_cmp expect output
> '
This is one is trying to do a multi-file lookup, but we couldn't look in
the system config before. But to naturally extend it, it ought to look
like this on top:
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index d2476a8..4dd5ce3 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1310,11 +1310,12 @@ test_expect_success '--show-origin with single file' '
test_expect_success '--show-origin with --get-regexp' '
cat >expect <<-EOF &&
+ file:$HOME/etc-gitconfig user.system true
file:$HOME/.gitconfig user.global true
file:.git/config user.local true
EOF
GIT_ETC_GITCONFIG=$HOME/etc-gitconfig \
- git config --show-origin --get-regexp "user\.[g|l].*" >output &&
+ git config --show-origin --get-regexp "user\.[g|l|s].*" >output &&
test_cmp expect output
'
> @@ -1312,6 +1324,7 @@ test_expect_success '--show-origin getting a single key' '
> cat >expect <<-\EOF &&
> file:.git/config local
> EOF
> + GIT_CONFIG_SYSTEM_PATH=$HOME/etc-gitconfig \
> git config --show-origin user.override >output &&
> test_cmp expect output
> '
And I was tempted to say this one should not need to care, but I guess
it is testing that we correctly read the override from the local config
over the global one. So likewise, it is good to check that we also
override the system config (it does not effect the "expect" output, but
that does not mean it is not enhancing the test).
-Peff
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox