* [PATCH v6 1/4] git: make super-prefix option
From: Brandon Williams @ 2016-09-29 21:48 UTC (permalink / raw)
To: git; +Cc: Brandon Williams, sbeller, peff, gitster
In-Reply-To: <1475185723-36871-1-git-send-email-bmwill@google.com>
Add a super-prefix environment variable 'GIT_INTERNAL_SUPER_PREFIX'
which can be used to specify a path from above a repository down to its
root. When such a super-prefix is specified, the paths reported by Git
are prefixed with it to make them relative to that directory "above".
The paths given by the user on the command line
(e.g. "git subcmd --output-file=path/to/a/file" and pathspecs) are taken
relative to the directory "above" to match.
The immediate use of this option is by commands which have a
--recurse-submodule option in order to give context to submodules about
how they were invoked. This option is currently only allowed for
builtins which support a super-prefix.
Signed-off-by: Brandon Williams <bmwill@google.com>
---
Documentation/git.txt | 6 ++++++
cache.h | 2 ++
environment.c | 10 ++++++++++
git.c | 26 ++++++++++++++++++++++++++
4 files changed, 44 insertions(+)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 7913fc2..2188ae6 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -13,6 +13,7 @@ SYNOPSIS
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
+ [--super-prefix=<path>]
<command> [<args>]
DESCRIPTION
@@ -601,6 +602,11 @@ foo.bar= ...`) sets `foo.bar` to the empty string.
details. Equivalent to setting the `GIT_NAMESPACE` environment
variable.
+--super-prefix=<path>::
+ Currently for internal use only. Set a prefix which gives a path from
+ above a repository down to its root. One use is to give submodules
+ context about the superproject that invoked it.
+
--bare::
Treat the repository as a bare repository. If GIT_DIR
environment is not set, it is set to the current working
diff --git a/cache.h b/cache.h
index 3556326..8cf495d 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_SUPER_PREFIX_ENVIRONMENT "GIT_INTERNAL_SUPER_PREFIX"
#define DEFAULT_GIT_DIR_ENVIRONMENT ".git"
#define DB_ENVIRONMENT "GIT_OBJECT_DIRECTORY"
#define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
@@ -468,6 +469,7 @@ extern int get_common_dir_noenv(struct strbuf *sb, const char *gitdir);
extern int get_common_dir(struct strbuf *sb, const char *gitdir);
extern const char *get_git_namespace(void);
extern const char *strip_namespace(const char *namespaced_ref);
+extern const char *get_super_prefix(void);
extern const char *get_git_work_tree(void);
/*
diff --git a/environment.c b/environment.c
index ca72464..13f3d70 100644
--- a/environment.c
+++ b/environment.c
@@ -100,6 +100,8 @@ static char *work_tree;
static const char *namespace;
static size_t namespace_len;
+static const char *super_prefix;
+
static const char *git_dir, *git_common_dir;
static char *git_object_dir, *git_index_file, *git_graft_file;
int git_db_env, git_index_env, git_graft_env, git_common_dir_env;
@@ -120,6 +122,7 @@ const char * const local_repo_env[] = {
NO_REPLACE_OBJECTS_ENVIRONMENT,
GIT_REPLACE_REF_BASE_ENVIRONMENT,
GIT_PREFIX_ENVIRONMENT,
+ GIT_SUPER_PREFIX_ENVIRONMENT,
GIT_SHALLOW_FILE_ENVIRONMENT,
GIT_COMMON_DIR_ENVIRONMENT,
NULL
@@ -222,6 +225,13 @@ const char *strip_namespace(const char *namespaced_ref)
return namespaced_ref + namespace_len;
}
+const char *get_super_prefix(void)
+{
+ if (!super_prefix)
+ super_prefix = getenv(GIT_SUPER_PREFIX_ENVIRONMENT);
+ return super_prefix;
+}
+
static int git_work_tree_initialized;
/*
diff --git a/git.c b/git.c
index 1c61151..f756b62 100644
--- a/git.c
+++ b/git.c
@@ -164,6 +164,20 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
setenv(GIT_WORK_TREE_ENVIRONMENT, cmd, 1);
if (envchanged)
*envchanged = 1;
+ } else if (!strcmp(cmd, "--super-prefix")) {
+ if (*argc < 2) {
+ fprintf(stderr, "No prefix given for --super-prefix.\n" );
+ usage(git_usage_string);
+ }
+ setenv(GIT_SUPER_PREFIX_ENVIRONMENT, (*argv)[1], 1);
+ if (envchanged)
+ *envchanged = 1;
+ (*argv)++;
+ (*argc)--;
+ } else if (skip_prefix(cmd, "--super-prefix=", &cmd)) {
+ setenv(GIT_SUPER_PREFIX_ENVIRONMENT, cmd, 1);
+ if (envchanged)
+ *envchanged = 1;
} else if (!strcmp(cmd, "--bare")) {
char *cwd = xgetcwd();
is_bare_repository_cfg = 1;
@@ -310,6 +324,7 @@ static int handle_alias(int *argcp, const char ***argv)
* RUN_SETUP for reading from the configuration file.
*/
#define NEED_WORK_TREE (1<<3)
+#define SUPPORT_SUPER_PREFIX (1<<4)
struct cmd_struct {
const char *cmd;
@@ -344,6 +359,13 @@ static int run_builtin(struct cmd_struct *p, int argc, const char **argv)
}
commit_pager_choice();
+ if (!help && get_super_prefix()) {
+ if (!(p->option & SUPPORT_SUPER_PREFIX))
+ die("%s doesn't support --super-prefix", p->cmd);
+ if (prefix)
+ die("can't use --super-prefix from a subdirectory");
+ }
+
if (!help && p->option & NEED_WORK_TREE)
setup_work_tree();
@@ -558,6 +580,10 @@ static void execv_dashed_external(const char **argv)
const char *tmp;
int status;
+ if (get_super_prefix()) {
+ die("%s doesn't support --super-prefix", argv[0]);
+ }
+
if (use_pager == -1)
use_pager = check_pager_config(argv[0]);
commit_pager_choice();
--
2.10.0
^ permalink raw reply related
* [PATCH v6 0/4] recursive support for ls-files
From: Brandon Williams @ 2016-09-29 21:48 UTC (permalink / raw)
To: git; +Cc: Brandon Williams, sbeller, peff, gitster
In-Reply-To: <1475099443-145608-1-git-send-email-bmwill@google.com>
Minor fixes per the comments on version 5.
Brandon Williams (4):
git: make super-prefix option
ls-files: optionally recurse into submodules
ls-files: pass through safe options for --recurse-submodules
ls-files: add pathspec matching for submodules
Documentation/git-ls-files.txt | 7 +-
Documentation/git.txt | 6 +
builtin/ls-files.c | 202 ++++++++++++++++++++++++-------
cache.h | 2 +
dir.c | 46 +++++++-
dir.h | 4 +
environment.c | 10 ++
git.c | 28 ++++-
t/t3007-ls-files-recurse-submodules.sh | 209 +++++++++++++++++++++++++++++++++
9 files changed, 470 insertions(+), 44 deletions(-)
create mode 100755 t/t3007-ls-files-recurse-submodules.sh
--
2.10.0
^ permalink raw reply
* Re: [PATCH v2 02/11] i18n: add--interactive: mark simple here documents for translation
From: Junio C Hamano @ 2016-09-29 21:31 UTC (permalink / raw)
To: Jakub Narębski
Cc: Vasco Almeida, git, Jiang Xin,
Ævar Arnfjörð Bjarmason, David Aguilar
In-Reply-To: <07371844-7fde-5b7f-b9e1-7db1a54fdbb5@gmail.com>
Jakub Narębski <jnareb@gmail.com> writes:
> W dniu 29.09.2016 o 19:05, Junio C Hamano pisze:
>> Vasco Almeida <vascomalmeida@sapo.pt> writes:
>>
>>> On the other hand, would it make sense to translate these commands? If
>>> so, we would mark for translation the commands name of @cmd in
>>> main_loop().
>>>
>>> sub main_loop {
>>> - my @cmd = ([ 'status', \&status_cmd, ],
>>> - [ 'update', \&update_cmd, ],
>>> - [ 'revert', \&revert_cmd, ],
>>> - [ 'add untracked', \&add_untracked_cmd, ],
>>> - [ 'patch', \&patch_update_cmd, ],
>>> - [ 'diff', \&diff_cmd, ],
>>> - [ 'quit', \&quit_cmd, ],
>>> - [ 'help', \&help_cmd, ],
>>> + my @cmd = ([ __('status'), \&status_cmd, ],
>>> + [ __('update'), \&update_cmd, ],
>>> + [ __('revert'), \&revert_cmd, ],
>>> + [ __('add untracked'), \&add_untracked_cmd, ],
>>> + [ __('patch'), \&patch_update_cmd, ],
>>> + [ __('diff'), \&diff_cmd, ],
>>> + [ __('quit'), \&quit_cmd, ],
>>> + [ __('help'), \&help_cmd, ],
>>
>> I don't know offhand. If the code to prompt and accept the command
>> given by the user can take the translated word (or a prefix of it),
>> theoretically I would say it could be made to work, but to me it is
>> dubious the benefit outweighs its downsides. It would make teaching
>> Git and troubleshooting over the phone harder, I would guess.
>>
>> A: "Hi, I am in a 'git add -i' session."
>> B: "Give 's' at the prompt."
>> A: "My Git does not seem to take 's' as a valid command."
>> B: "What? I've never seen that problem."
>> ... back and forth wastes 10 minutes ...
>> A: "By the way, I am running Git in Portuguese."
>
> Also, for one-letter commands to work (there is setting where you
> don't even need to press enter, IIRC) all those translations would
> have to be chosen to begin with different letter, isn't it?
The original was written with an explicit expectation that these
command words will not be translated adn chose words that do not
share the first letter exactly for that reason.
Having said that, if somebody is willing to i18n the command words,
I'd expect that the command line prompt interaction would be updated
to take the unique prefix instead of the "first byte", and if that
happens, I think the resulting system would at least be internally
consistent.
It is still dubious to me if the benefit of i18n outweighs its
downsides, though.
^ permalink raw reply
* Re: [PATCH v2 02/11] i18n: add--interactive: mark simple here documents for translation
From: Jakub Narębski @ 2016-09-29 21:27 UTC (permalink / raw)
To: Junio C Hamano, Vasco Almeida
Cc: git, Jiang Xin, Ævar Arnfjörð Bjarmason,
David Aguilar
In-Reply-To: <xmqqfuoihc1m.fsf@gitster.mtv.corp.google.com>
W dniu 29.09.2016 o 19:05, Junio C Hamano pisze:
> Vasco Almeida <vascomalmeida@sapo.pt> writes:
>
>> On the other hand, would it make sense to translate these commands? If
>> so, we would mark for translation the commands name of @cmd in
>> main_loop().
>>
>> sub main_loop {
>> - my @cmd = ([ 'status', \&status_cmd, ],
>> - [ 'update', \&update_cmd, ],
>> - [ 'revert', \&revert_cmd, ],
>> - [ 'add untracked', \&add_untracked_cmd, ],
>> - [ 'patch', \&patch_update_cmd, ],
>> - [ 'diff', \&diff_cmd, ],
>> - [ 'quit', \&quit_cmd, ],
>> - [ 'help', \&help_cmd, ],
>> + my @cmd = ([ __('status'), \&status_cmd, ],
>> + [ __('update'), \&update_cmd, ],
>> + [ __('revert'), \&revert_cmd, ],
>> + [ __('add untracked'), \&add_untracked_cmd, ],
>> + [ __('patch'), \&patch_update_cmd, ],
>> + [ __('diff'), \&diff_cmd, ],
>> + [ __('quit'), \&quit_cmd, ],
>> + [ __('help'), \&help_cmd, ],
>
> I don't know offhand. If the code to prompt and accept the command
> given by the user can take the translated word (or a prefix of it),
> theoretically I would say it could be made to work, but to me it is
> dubious the benefit outweighs its downsides. It would make teaching
> Git and troubleshooting over the phone harder, I would guess.
>
> A: "Hi, I am in a 'git add -i' session."
> B: "Give 's' at the prompt."
> A: "My Git does not seem to take 's' as a valid command."
> B: "What? I've never seen that problem."
> ... back and forth wastes 10 minutes ...
> A: "By the way, I am running Git in Portuguese."
Also, for one-letter commands to work (there is setting where you
don't even need to press enter, IIRC) all those translations would
have to be chosen to begin with different letter, isn't it?
Best,
--
Jakub Narębski
^ permalink raw reply
* 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
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