* Re: [PATCH] refs: parse_hide_refs_config to use parse_config_key
From: Jeff King @ 2017-02-24 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stefan Beller, git
In-Reply-To: <xmqq4lzj1e4n.fsf@gitster.mtv.corp.google.com>
On Fri, Feb 24, 2017 at 01:18:48PM -0800, Junio C Hamano wrote:
> > While I'm thinking about it, here are patches to do that. The third one
> > I'd probably squash into yours (after ordering it to the end).
> >
> > [1/3]: parse_config_key: use skip_prefix instead of starts_with
> > [2/3]: parse_config_key: allow matching single-level config
> > [3/3]: parse_hide_refs_config: tell parse_config_key we don't want a subsection
>
> While you were doing that, I was grepping the call sites for
> parse_config_key() and made sure that all of them are OK when fed
> two level names. Most of them follow this pattern:
>
> if (parse_config_key(k, "diff", &name, &namelen, &type) || !name)
> return -1;
>
> and ones that do not immediately check !name does either eventually
> do so or have separate codepaths for handlihng two- and three-level
> names.
Yeah, I did that, too. :)
I don't think there are any other sites to convert. And I don't think we
can make the "!name" case easier (because some call-sites do want to
handle both types). And it's not like it gets much easier anyway (unlike
the opposite case, you _do_ need to declare the extra variables.
-Peff
^ permalink raw reply
* Re: [PATCH] refs: parse_hide_refs_config to use parse_config_key
From: Junio C Hamano @ 2017-02-24 21:18 UTC (permalink / raw)
To: Jeff King; +Cc: Stefan Beller, git
In-Reply-To: <20170224210643.max6z2ykm3gbg7lw@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 24, 2017 at 03:39:40PM -0500, Jeff King wrote:
>
>> This will start parsing "receive.foobar.hiderefs", which we don't want.
>> I think you need:
>>
>> !parse_config_key(var, section, &subsection, &subsection_len, &key) &&
>> !subsection &&
>> !strcmp(key, "hiderefs")
>>
>> Perhaps passing NULL for the subsection variable should cause
>> parse_config_key to return failure when there is a non-empty subsection.
>>
>> -Peff
>>
>> PS Outside of parse_config_key, this code would be nicer if it used
>> skip_prefix() instead of starts_with(). Since it's going away, I
>> don't think it matters, but I note that parse_config_key could
>> probably benefit from the same.
>
> While I'm thinking about it, here are patches to do that. The third one
> I'd probably squash into yours (after ordering it to the end).
>
> [1/3]: parse_config_key: use skip_prefix instead of starts_with
> [2/3]: parse_config_key: allow matching single-level config
> [3/3]: parse_hide_refs_config: tell parse_config_key we don't want a subsection
While you were doing that, I was grepping the call sites for
parse_config_key() and made sure that all of them are OK when fed
two level names. Most of them follow this pattern:
if (parse_config_key(k, "diff", &name, &namelen, &type) || !name)
return -1;
and ones that do not immediately check !name does either eventually
do so or have separate codepaths for handlihng two- and three-level
names.
^ permalink raw reply
* [PATCH 3/3] parse_hide_refs_config: tell parse_config_key we don't want a subsection
From: Jeff King @ 2017-02-24 21:08 UTC (permalink / raw)
To: Stefan Beller; +Cc: gitster, git
In-Reply-To: <20170224210643.max6z2ykm3gbg7lw@sigill.intra.peff.net>
This lets us avoid declaring some otherwise useless
variables.
Signed-off-by: Jeff King <peff@peff.net>
---
refs.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 21bc8c910..b9188908b 100644
--- a/refs.c
+++ b/refs.c
@@ -1034,11 +1034,10 @@ static struct string_list *hide_refs;
int parse_hide_refs_config(const char *var, const char *value, const char *section)
{
- const char *subsection, *key;
- int subsection_len;
+ const char *key;
if (!strcmp("transfer.hiderefs", var) ||
- (!parse_config_key(var, section, &subsection, &subsection_len, &key)
- && !subsection && !strcmp(key, "hiderefs"))) {
+ (!parse_config_key(var, section, NULL, NULL, &key) &&
+ !strcmp(key, "hiderefs"))) {
char *ref;
int len;
--
2.12.0.616.g5f622f3b1
^ permalink raw reply related
* [PATCH 2/3] parse_config_key: allow matching single-level config
From: Jeff King @ 2017-02-24 21:08 UTC (permalink / raw)
To: Stefan Beller; +Cc: gitster, git
In-Reply-To: <20170224210643.max6z2ykm3gbg7lw@sigill.intra.peff.net>
The parse_config_key() function was introduced to make it
easier to match "section.subsection.key" variables. It also
handles the simpler "section.key", and the caller is
responsible for distinguishing the two from its
out-parameters.
Most callers who _only_ want "section.key" would just use a
strcmp(var, "section.key"), since there is no parsing
required. However, they may still use parse_config_key() if
their "section" variable isn't a constant (an example of
this is in parse_hide_refs_config).
Using the parse_config_key is a bit clunky, though:
const char *subsection;
int subsection_len;
const char *key;
if (!parse_config_key(var, section, &subsection, &subsection_len, &key) &&
!subsection) {
/* matched! */
}
Instead, let's treat a NULL subsection as an indication that
the caller does not expect one. That lets us write:
const char *key;
if (!parse_config_key(var, section, NULL, NULL, &key)) {
/* matched! */
}
Existing callers should be unaffected, as passing a NULL
subsection would currently segfault.
Signed-off-by: Jeff King <peff@peff.net>
---
cache.h | 5 ++++-
config.c | 8 ++++++--
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index 61fc86e6d..647a78f3f 100644
--- a/cache.h
+++ b/cache.h
@@ -1819,8 +1819,11 @@ extern int git_config_include(const char *name, const char *value, void *data);
*
* (i.e., what gets handed to a config_fn_t). The caller provides the section;
* we return -1 if it does not match, 0 otherwise. The subsection and key
- * out-parameters are filled by the function (and subsection is NULL if it is
+ * out-parameters are filled by the function (and *subsection is NULL if it is
* missing).
+ *
+ * If the subsection pointer-to-pointer passed in is NULL, returns 0 only if
+ * there is no subsection at all.
*/
extern int parse_config_key(const char *var,
const char *section,
diff --git a/config.c b/config.c
index 1b08a75a7..13c8b21ea 100644
--- a/config.c
+++ b/config.c
@@ -2552,10 +2552,14 @@ int parse_config_key(const char *var,
/* Did we have a subsection at all? */
if (dot == var) {
- *subsection = NULL;
- *subsection_len = 0;
+ if (subsection) {
+ *subsection = NULL;
+ *subsection_len = 0;
+ }
}
else {
+ if (!subsection)
+ return -1;
*subsection = var + 1;
*subsection_len = dot - *subsection;
}
--
2.12.0.616.g5f622f3b1
^ permalink raw reply related
* [PATCH 1/3] parse_config_key: use skip_prefix instead of starts_with
From: Jeff King @ 2017-02-24 21:07 UTC (permalink / raw)
To: Stefan Beller; +Cc: gitster, git
In-Reply-To: <20170224210643.max6z2ykm3gbg7lw@sigill.intra.peff.net>
This saves us having to repeatedly add in "section_len" (and
also avoids walking over the first part of the string
multiple times for a strlen() and strrchr()).
Signed-off-by: Jeff King <peff@peff.net>
---
config.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/config.c b/config.c
index c6b874a7b..1b08a75a7 100644
--- a/config.c
+++ b/config.c
@@ -2536,11 +2536,10 @@ int parse_config_key(const char *var,
const char **subsection, int *subsection_len,
const char **key)
{
- int section_len = strlen(section);
const char *dot;
/* Does it start with "section." ? */
- if (!starts_with(var, section) || var[section_len] != '.')
+ if (!skip_prefix(var, section, &var) || *var != '.')
return -1;
/*
@@ -2552,12 +2551,12 @@ int parse_config_key(const char *var,
*key = dot + 1;
/* Did we have a subsection at all? */
- if (dot == var + section_len) {
+ if (dot == var) {
*subsection = NULL;
*subsection_len = 0;
}
else {
- *subsection = var + section_len + 1;
+ *subsection = var + 1;
*subsection_len = dot - *subsection;
}
--
2.12.0.616.g5f622f3b1
^ permalink raw reply related
* Re: [PATCH] refs: parse_hide_refs_config to use parse_config_key
From: Jeff King @ 2017-02-24 21:06 UTC (permalink / raw)
To: Stefan Beller; +Cc: gitster, git
In-Reply-To: <20170224203940.hbmfsouw5k67l3h3@sigill.intra.peff.net>
On Fri, Feb 24, 2017 at 03:39:40PM -0500, Jeff King wrote:
> This will start parsing "receive.foobar.hiderefs", which we don't want.
> I think you need:
>
> !parse_config_key(var, section, &subsection, &subsection_len, &key) &&
> !subsection &&
> !strcmp(key, "hiderefs")
>
> Perhaps passing NULL for the subsection variable should cause
> parse_config_key to return failure when there is a non-empty subsection.
>
> -Peff
>
> PS Outside of parse_config_key, this code would be nicer if it used
> skip_prefix() instead of starts_with(). Since it's going away, I
> don't think it matters, but I note that parse_config_key could
> probably benefit from the same.
While I'm thinking about it, here are patches to do that. The third one
I'd probably squash into yours (after ordering it to the end).
[1/3]: parse_config_key: use skip_prefix instead of starts_with
[2/3]: parse_config_key: allow matching single-level config
[3/3]: parse_hide_refs_config: tell parse_config_key we don't want a subsection
cache.h | 5 ++++-
config.c | 15 +++++++++------
refs.c | 7 +++----
3 files changed, 16 insertions(+), 11 deletions(-)
^ permalink raw reply
* Re: [PATCH 01/10] submodule: decouple url and submodule existence
From: Junio C Hamano @ 2017-02-24 21:02 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, sbeller
In-Reply-To: <20170223234728.164111-2-bmwill@google.com>
Brandon Williams <bmwill@google.com> writes:
> Currently the submodule.<name>.url config option is used to determine
> if a given submodule exists and is interesting to the user. This
> however doesn't work very well because the URL is a config option for
> the scope of a repository, whereas the existence of a submodule is an
> option scoped to the working tree.
>
> In a future with worktree support for submodules, there will be multiple
> working trees, each of which may only need a subset of the submodules
> checked out. The URL (which is where the submodule repository can be
> obtained) should not differ between different working trees.
>
> It may also be convenient for users to more easily specify groups of
> submodules they are interested in as apposed to running "git submodule
> init <path>" on each submodule they want checked out in their working
> tree.
>
> To this end, the config option submodule.active is introduced which
> holds a pathspec that specifies which submodules should exist in the
> working tree.
Hmph. submodule.active in .git/config would be shared the same way
submodule.<name>.url in .git/config is shared across the worktrees
that stems from the same primary repository, no?
Perhaps there are some other uses of this submodule.active idea, but
I do not see how it is relevant to solving "multiple worktrees"
issue. Per-worktree config would solve it with the current
submodule.<name>.url without submodule.active list, I would think [*1*].
Also as a grouping measure, submodule.active that lists submodule
paths feels hard to use. When switching between two branches in the
superproject that have the same submodule bound at two different
paths, who is responsible for updating submodule.active in
superproject's config? If it were a list of submodule names, this
objection does not apply, though.
[Footnote]
*1* At the conceptual level, I agree that .url that also means "we
are interested in this one" feels like somewhat an unclean
design, but that is not what you are "fixing", is it?
^ permalink raw reply
* Re: [PATCH] refs: parse_hide_refs_config to use parse_config_key
From: Junio C Hamano @ 2017-02-24 20:47 UTC (permalink / raw)
To: Stefan Beller; +Cc: peff, git
In-Reply-To: <20170224204335.10652-1-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> parse_config_key was introduced in 1b86bbb0ade (config: add helper
> function for parsing key names, 2013-01-22), the NEEDSWORK that is removed
> in this patch was introduced at daebaa7813 (upload/receive-pack: allow
> hiding ref hierarchies, 2013-01-18), which is only a couple days apart,
> so presumably the code replaced in this patch was only introduced due
> to not wanting to wait on the proper helper function being available.
>
> Make the condition easier to read by using parse_config_key.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> refs.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index cd36b64ed9..21bc8c9101 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -1034,10 +1034,11 @@ static struct string_list *hide_refs;
>
> int parse_hide_refs_config(const char *var, const char *value, const char *section)
> {
> + const char *subsection, *key;
> + int subsection_len;
> if (!strcmp("transfer.hiderefs", var) ||
> - /* NEEDSWORK: use parse_config_key() once both are merged */
> - (starts_with(var, section) && var[strlen(section)] == '.' &&
> - !strcmp(var + strlen(section), ".hiderefs"))) {
> + (!parse_config_key(var, section, &subsection, &subsection_len, &key)
> + && !subsection && !strcmp(key, "hiderefs"))) {
> char *ref;
> int len;
Thanks for noticing. "once both are merged" is a cryptic comment to
leave when somebody knows which two topics make "both" ;-)
^ permalink raw reply
* Re: [PATCH] refs: parse_hide_refs_config to use parse_config_key
From: Jeff King @ 2017-02-24 20:47 UTC (permalink / raw)
To: Stefan Beller; +Cc: gitster, git
In-Reply-To: <20170224204335.10652-1-sbeller@google.com>
On Fri, Feb 24, 2017 at 12:43:35PM -0800, Stefan Beller wrote:
> parse_config_key was introduced in 1b86bbb0ade (config: add helper
> function for parsing key names, 2013-01-22), the NEEDSWORK that is removed
> in this patch was introduced at daebaa7813 (upload/receive-pack: allow
> hiding ref hierarchies, 2013-01-18), which is only a couple days apart,
> so presumably the code replaced in this patch was only introduced due
> to not wanting to wait on the proper helper function being available.
>
> Make the condition easier to read by using parse_config_key.
> [...]
> if (!strcmp("transfer.hiderefs", var) ||
> - /* NEEDSWORK: use parse_config_key() once both are merged */
> - (starts_with(var, section) && var[strlen(section)] == '.' &&
> - !strcmp(var + strlen(section), ".hiderefs"))) {
> + (!parse_config_key(var, section, &subsection, &subsection_len, &key)
> + && !subsection && !strcmp(key, "hiderefs"))) {
Yeah, this one looks fine.
-Peff
^ permalink raw reply
* [PATCH] refs: parse_hide_refs_config to use parse_config_key
From: Stefan Beller @ 2017-02-24 20:43 UTC (permalink / raw)
To: gitster, peff; +Cc: git, Stefan Beller
In-Reply-To: <20170224203940.hbmfsouw5k67l3h3@sigill.intra.peff.net>
parse_config_key was introduced in 1b86bbb0ade (config: add helper
function for parsing key names, 2013-01-22), the NEEDSWORK that is removed
in this patch was introduced at daebaa7813 (upload/receive-pack: allow
hiding ref hierarchies, 2013-01-18), which is only a couple days apart,
so presumably the code replaced in this patch was only introduced due
to not wanting to wait on the proper helper function being available.
Make the condition easier to read by using parse_config_key.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
refs.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index cd36b64ed9..21bc8c9101 100644
--- a/refs.c
+++ b/refs.c
@@ -1034,10 +1034,11 @@ static struct string_list *hide_refs;
int parse_hide_refs_config(const char *var, const char *value, const char *section)
{
+ const char *subsection, *key;
+ int subsection_len;
if (!strcmp("transfer.hiderefs", var) ||
- /* NEEDSWORK: use parse_config_key() once both are merged */
- (starts_with(var, section) && var[strlen(section)] == '.' &&
- !strcmp(var + strlen(section), ".hiderefs"))) {
+ (!parse_config_key(var, section, &subsection, &subsection_len, &key)
+ && !subsection && !strcmp(key, "hiderefs"))) {
char *ref;
int len;
--
2.12.0.rc1.16.ge4278d41a0.dirty
^ permalink raw reply related
* [PATCH] refs: parse_hide_refs_config to use parse_config_key
From: Stefan Beller @ 2017-02-24 20:33 UTC (permalink / raw)
To: gitster, peff; +Cc: git, Stefan Beller
parse_config_key was introduced in 1b86bbb0ade (config: add helper
function for parsing key names, 2013-01-22), the NEEDSWORK that is removed
in this patch was introduced at daebaa7813 (upload/receive-pack: allow
hiding ref hierarchies, 2013-01-18), which is only a couple days apart,
so presumably the code replaced in this patch was only introduced due
to not wanting to wait on the proper helper function being available.
Make the condition easier to read by using parse_config_key.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
When investigating the state of the art for parsing config options, I saw
opportunity for a small drive-by patch in an area that I did not look at for
a long time.
The authors of the two mentioned commits are Jeff and Junio, so maybe you
remember another reason for this NEEDSWORK here?
Thanks,
Stefan
refs.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/refs.c b/refs.c
index cd36b64ed9..c9e5f13630 100644
--- a/refs.c
+++ b/refs.c
@@ -1034,10 +1034,11 @@ static struct string_list *hide_refs;
int parse_hide_refs_config(const char *var, const char *value, const char *section)
{
+ const char *subsection, *key;
+ int subsection_len;
if (!strcmp("transfer.hiderefs", var) ||
- /* NEEDSWORK: use parse_config_key() once both are merged */
- (starts_with(var, section) && var[strlen(section)] == '.' &&
- !strcmp(var + strlen(section), ".hiderefs"))) {
+ (!parse_config_key(var, section, &subsection, &subsection_len, &key)
+ && !strcmp(key, "hiderefs"))) {
char *ref;
int len;
--
2.12.0.rc1.16.ge4278d41a0.dirty
^ permalink raw reply related
* Re: [PATCH] refs: parse_hide_refs_config to use parse_config_key
From: Jeff King @ 2017-02-24 20:39 UTC (permalink / raw)
To: Stefan Beller; +Cc: gitster, git
In-Reply-To: <20170224203335.3762-1-sbeller@google.com>
On Fri, Feb 24, 2017 at 12:33:35PM -0800, Stefan Beller wrote:
> parse_config_key was introduced in 1b86bbb0ade (config: add helper
> function for parsing key names, 2013-01-22), the NEEDSWORK that is removed
> in this patch was introduced at daebaa7813 (upload/receive-pack: allow
> hiding ref hierarchies, 2013-01-18), which is only a couple days apart,
> so presumably the code replaced in this patch was only introduced due
> to not wanting to wait on the proper helper function being available.
>
> Make the condition easier to read by using parse_config_key.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>
> When investigating the state of the art for parsing config options, I saw
> opportunity for a small drive-by patch in an area that I did not look at for
> a long time.
>
> The authors of the two mentioned commits are Jeff and Junio, so maybe you
> remember another reason for this NEEDSWORK here?
No, I think the reasoning you gave in the commit message is exactly
what happened.
> diff --git a/refs.c b/refs.c
> index cd36b64ed9..c9e5f13630 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -1034,10 +1034,11 @@ static struct string_list *hide_refs;
>
> int parse_hide_refs_config(const char *var, const char *value, const char *section)
> {
> + const char *subsection, *key;
> + int subsection_len;
> if (!strcmp("transfer.hiderefs", var) ||
> - /* NEEDSWORK: use parse_config_key() once both are merged */
> - (starts_with(var, section) && var[strlen(section)] == '.' &&
> - !strcmp(var + strlen(section), ".hiderefs"))) {
> + (!parse_config_key(var, section, &subsection, &subsection_len, &key)
> + && !strcmp(key, "hiderefs"))) {
This will start parsing "receive.foobar.hiderefs", which we don't want.
I think you need:
!parse_config_key(var, section, &subsection, &subsection_len, &key) &&
!subsection &&
!strcmp(key, "hiderefs")
Perhaps passing NULL for the subsection variable should cause
parse_config_key to return failure when there is a non-empty subsection.
-Peff
PS Outside of parse_config_key, this code would be nicer if it used
skip_prefix() instead of starts_with(). Since it's going away, I
don't think it matters, but I note that parse_config_key could
probably benefit from the same.
^ permalink raw reply
* [PATCH v2 2/2] Documentation: Link descriptions of -z to core.quotePath
From: Andreas Heiduk @ 2017-02-24 20:37 UTC (permalink / raw)
To: gitster; +Cc: Andreas Heiduk, git
In-Reply-To: <1487968676-6126-1-git-send-email-asheiduk@gmail.com>
Linking the description for pathname quoting to the configuration
variable "core.quotePath" removes inconstistent and incomplete
sections while also giving two hints how to deal with it: Either with
"-c core.quotePath=false" or with "-z".
Signed-off-by: Andreas Heiduk <asheiduk@gmail.com>
---
Documentation/diff-format.txt | 7 ++++---
Documentation/diff-generate-patch.txt | 7 +++----
Documentation/diff-options.txt | 7 +++----
Documentation/git-apply.txt | 7 +++----
Documentation/git-commit.txt | 9 ++++++---
Documentation/git-ls-files.txt | 10 ++++++----
Documentation/git-ls-tree.txt | 10 +++++++---
Documentation/git-status.txt | 7 +++----
8 files changed, 35 insertions(+), 29 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index cf52626..706916c 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -78,9 +78,10 @@ Example:
:100644 100644 5be4a4...... 000000...... M file.c
------------------------------------------------
-When `-z` option is not used, TAB, LF, and backslash characters
-in pathnames are represented as `\t`, `\n`, and `\\`,
-respectively.
+Without the `-z` option, pathnames with "unusual" characters are
+quoted as explained for the configuration variable `core.quotePath`
+(see linkgit:git-config[1]). Using `-z` the filename is output
+verbatim and the line is terminated by a NUL byte.
diff format for merges
----------------------
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
index d2a7ff5..231105c 100644
--- a/Documentation/diff-generate-patch.txt
+++ b/Documentation/diff-generate-patch.txt
@@ -53,10 +53,9 @@ The index line includes the SHA-1 checksum before and after the change.
The <mode> is included if the file mode does not change; otherwise,
separate lines indicate the old and the new mode.
-3. TAB, LF, double quote and backslash characters in pathnames
- are represented as `\t`, `\n`, `\"` and `\\`, respectively.
- If there is need for such substitution then the whole
- pathname is put in double quotes.
+3. Pathnames with "unusual" characters are quoted as explained for
+ the configuration variable `core.quotePath` (see
+ linkgit:git-config[1]).
4. All the `file1` files in the output refer to files before the
commit, and all the `file2` files refer to files after the commit.
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index e6215c3..7c28e73 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -192,10 +192,9 @@ ifndef::git-log[]
given, do not munge pathnames and use NULs as output field terminators.
endif::git-log[]
+
-Without this option, each pathname output will have TAB, LF, double quotes,
-and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`,
-respectively, and the pathname will be enclosed in double quotes if
-any of those replacements occurred.
+Without this option, pathnames with "unusual" characters are munged as
+explained for the configuration variable `core.quotePath` (see
+linkgit:git-config[1]).
--name-only::
Show only names of changed files.
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index 8ddb207..a7a001b 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -108,10 +108,9 @@ the information is read from the current index instead.
When `--numstat` has been given, do not munge pathnames,
but use a NUL-terminated machine-readable format.
+
-Without this option, each pathname output will have TAB, LF, double quotes,
-and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`,
-respectively, and the pathname will be enclosed in double quotes if
-any of those replacements occurred.
+Without this option, pathnames with "unusual" characters are munged as
+explained for the configuration variable `core.quotePath` (see
+linkgit:git-config[1]).
-p<n>::
Remove <n> leading slashes from traditional diff paths. The
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 4f8f20a..25dcdcc 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -117,9 +117,12 @@ OPTIONS
-z::
--null::
- When showing `short` or `porcelain` status output, terminate
- entries in the status output with NUL, instead of LF. If no
- format is given, implies the `--porcelain` output format.
+ When showing `short` or `porcelain` status output, print the
+ filename verbatim and terminate the entries with NUL, instead of LF.
+ If no format is given, implies the `--porcelain` output format.
+ Without the `-z` option, filenames with "unusual" characters are
+ quoted as explained for the configuration variable `core.quotePath`
+ (see linkgit:git-config[1]).
-F <file>::
--file=<file>::
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 446209e..1cab703 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -77,7 +77,8 @@ OPTIONS
succeed.
-z::
- \0 line termination on output.
+ \0 line termination on output and do not quote filenames.
+ See OUTPUT below for more information.
-x <pattern>::
--exclude=<pattern>::
@@ -196,9 +197,10 @@ the index records up to three such pairs; one from tree O in stage
the user (or the porcelain) to see what should eventually be recorded at the
path. (see linkgit:git-read-tree[1] for more information on state)
-When `-z` option is not used, TAB, LF, and backslash characters
-in pathnames are represented as `\t`, `\n`, and `\\`,
-respectively.
+Without the `-z` option, pathnames with "unusual" characters are
+quoted as explained for the configuration variable `core.quotePath`
+(see linkgit:git-config[1]). Using `-z` the filename is output
+verbatim and the line is terminated by a NUL byte.
Exclude Patterns
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index dbc91f9..9dee7be 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -53,7 +53,8 @@ OPTIONS
Show object size of blob (file) entries.
-z::
- \0 line termination on output.
+ \0 line termination on output and do not quote filenames.
+ See OUTPUT FORMAT below for more information.
--name-only::
--name-status::
@@ -82,8 +83,6 @@ Output Format
-------------
<mode> SP <type> SP <object> TAB <file>
-Unless the `-z` option is used, TAB, LF, and backslash characters
-in pathnames are represented as `\t`, `\n`, and `\\`, respectively.
This output format is compatible with what `--index-info --stdin` of
'git update-index' expects.
@@ -95,6 +94,11 @@ Object size identified by <object> is given in bytes, and right-justified
with minimum width of 7 characters. Object size is given only for blobs
(file) entries; for other entries `-` character is used in place of size.
+Without the `-z` option, pathnames with "unusual" characters are
+quoted as explained for the configuration variable `core.quotePath`
+(see linkgit:git-config[1]). Using `-z` the filename is output
+verbatim and the line is terminated by a NUL byte.
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index 725065e..ba87365 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -322,10 +322,9 @@ When the `-z` option is given, pathnames are printed as is and
without any quoting and lines are terminated with a NUL (ASCII 0x00)
byte.
-Otherwise, all pathnames will be "C-quoted" if they contain any tab,
-linefeed, double quote, or backslash characters. In C-quoting, these
-characters will be replaced with the corresponding C-style escape
-sequences and the resulting pathname will be double quoted.
+Without the `-z` option, pathnames with "unusual" characters are
+quoted as explained for the configuration variable `core.quotePath`
+(see linkgit:git-config[1]).
CONFIGURATION
^ permalink raw reply related
* [PATCH v2 1/2] Documentation: Improve description for core.quotePath
From: Andreas Heiduk @ 2017-02-24 20:37 UTC (permalink / raw)
To: gitster; +Cc: Andreas Heiduk, git
In-Reply-To: <1487968676-6126-1-git-send-email-asheiduk@gmail.com>
Signed-off-by: Andreas Heiduk <asheiduk@gmail.com>
---
Documentation/config.txt | 24 ++++++++++++++----------
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1fee83c..fa06c2a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -347,16 +347,20 @@ core.checkStat::
all fields, including the sub-second part of mtime and ctime.
core.quotePath::
- The commands that output paths (e.g. 'ls-files',
- 'diff'), when not given the `-z` option, will quote
- "unusual" characters in the pathname by enclosing the
- pathname in a double-quote pair and with backslashes the
- same way strings in C source code are quoted. If this
- variable is set to false, the bytes higher than 0x80 are
- not quoted but output as verbatim. Note that double
- quote, backslash and control characters are always
- quoted without `-z` regardless of the setting of this
- variable.
+
+ Commands that output paths (e.g. 'ls-files', 'diff'), will
+ quote "unusual" characters in the pathname by enclosing the
+ pathname in double-quotes and escaping those characters with
+ backslashes in the same way C escapes control characters (e.g.
+ `\t` for TAB, `\n` for LF, `\\` for backslash) or bytes with
+ values larger than 0x80 (e.g. octal `\302\265` for "micro" in
+ UTF-8). If this variable is set to false, bytes higher than
+ 0x80 are not considered "unusual" any more. Double-quotes,
+ backslash and control characters are always escaped regardless
+ of the setting of this variable. A simple space character is
+ not considered "unusual". Many commands can output pathnames
+ completely verbatim using the `-z` option. The default value
+ is true.
core.eol::
Sets the line ending type to use in the working directory for
^ permalink raw reply related
* [PATCH v2 0/2] Documentation: Link git-ls-files to core.quotePath variable.
From: Andreas Heiduk @ 2017-02-24 20:37 UTC (permalink / raw)
To: gitster; +Cc: Andreas Heiduk, git
In-Reply-To: <3c801e54-28c7-52d0-6915-ee7aaf1d89c9@gmail.com>
These two patches replace and extend the precious patches with the
same subject. Suggestions from Philip Oakley and Junio C Hamano are
included.
I tried to find and adjust all places where pathname quoting and "-z"
were described. I omitted these places:
* Here "-z" is for input only. Quoting is unclear to me.
-- git-mktree.txt
-- git-update-index.txt
-- git-checkout-index.txt
* Here pathname quoting is not mentioned:
-- git-check-ignore.txt
-- git-check-attr.txt
And last but not least:
- git-grep.txt: The paths are always unquoted, `-z` toggles only the
delimiter. Perhaps some CAVEAT should be added.
Andreas Heiduk (2):
Documentation: Improve description for core.quotePath
Documentation: Link descriptions of -z to core.quotePath
Documentation/config.txt | 24 ++++++++++++++----------
Documentation/diff-format.txt | 7 ++++---
Documentation/diff-generate-patch.txt | 7 +++----
Documentation/diff-options.txt | 7 +++----
Documentation/git-apply.txt | 7 +++----
Documentation/git-commit.txt | 9 ++++++---
Documentation/git-ls-files.txt | 10 ++++++----
Documentation/git-ls-tree.txt | 10 +++++++---
Documentation/git-status.txt | 7 +++----
9 files changed, 49 insertions(+), 39 deletions(-)
^ permalink raw reply
* Re: fatal error when diffing changed symlinks
From: Jeff King @ 2017-02-24 20:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Christophe Macabiau
In-Reply-To: <xmqqtw7j1i6d.fsf@gitster.mtv.corp.google.com>
On Fri, Feb 24, 2017 at 11:51:22AM -0800, Junio C Hamano wrote:
> > A slightly worse is that the upcoming Git will ship with a rewritten
> > "difftool" that makes the above sequence segfault.
>
> The culprit seems to be these lines in run_dir_diff():
>
> if (S_ISLNK(lmode)) {
> char *content = read_sha1_file(loid.hash, &type, &size);
> add_left_or_right(&symlinks2, src_path, content, 0);
> free(content);
> }
>
> if (S_ISLNK(rmode)) {
> char *content = read_sha1_file(roid.hash, &type, &size);
> add_left_or_right(&symlinks2, dst_path, content, 1);
> free(content);
> }
>
> When viewing a working tree file, oid.hash could be 0{40} and
> read_sha1_file() is not the right function to use to obtain the
> contents.
>
> Both of these two need to pay attention to 0{40}, I think, as the
> user may be running "difftool -R --dir-diff" in which case the
> working tree would appear in the left hand side instead.
As a side note, I think even outside of 0{40}, this should be checking
the return value of read_sha1_file(). A corrupted repo should die(), not
segfault.
-Peff
^ permalink raw reply
* Re: SHA1 collisions found
From: Philip Oakley @ 2017-02-24 20:33 UTC (permalink / raw)
To: Stefan Beller, Junio C Hamano; +Cc: David Lang, Ian Jackson, Joey Hess, git
In-Reply-To: <CAGZ79kaZWe-8pMZnQv7uZtr8wXWawFeJjUa68-b0oa4yFo-HcA@mail.gmail.com>
From: "Stefan Beller" <sbeller@google.com>
> On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano <gitster@pobox.com>
> wrote:
>
>> you are inviting people to start using
>>
>> md5,54ddf8d47340e048166c45f439ce65fd
>>
>> as object names.
>
> which might even be okay for specific subsets of operations.
> (e.g. all local work including staging things, making local "fixup"
> commits)
>
> The addressing scheme should not be too hardcoded, we should rather
> treat it similar to the cipher schemes in pgp. The additional complexity
> that
> we have is the longevity of existence of things, though.
>
One potential nicety of using the md5 is that it is a known `toy problem`
solution that could be used to explore how things might be made to work,
without any expectation that the temporary code is in any way an
experimental part of regular code. Maybe. It's good to have a toy problem to
work on.
There are other issue to be considered as well, such as validating a
transition of identical blobs and trees (at some point there will for some
users be a forced update of hash of unchanged code), which probably requires
two way traversal.
Philip
^ permalink raw reply
* Re: SHA1 collisions found
From: Junio C Hamano @ 2017-02-24 20:32 UTC (permalink / raw)
To: ankostis
Cc: Stefan Beller, David Lang, Ian Jackson, Joey Hess,
git@vger.kernel.org
In-Reply-To: <CA+dhYEVOyACM9ARP2deKVLm1hHOVsTah1WfGoNzGGKO6CGrQpw@mail.gmail.com>
ankostis <ankostis@gmail.com> writes:
> Let's assume that git is retroffited to always support the "default"
> SHA-3, but support additionally more hash-funcs.
> If in the future SHA-3 also gets defeated, it would be highly unlikely
> that the same math would also break e.g. Blake.
> So certain high-profile repos might choose for extra security 2 or more hashes.
I think you are conflating two unrelated things.
* How are these "2 or more hashes" actually used? Are you going to
add three "parent " line to a commit with just one parent, each
line storing the different hashes? How will such a commit object
be named---does it have three names and do you plan to have three
copies of .git/refs/heads/master somehow, each of which have
SHA-1, SHA-3 and Blake, and let any one hash to identify the
object?
I suspect you are not going to do so; instead, you would use a
very long string that is a concatenation of these three hashes as
if it is an output from a single hash function that produces a
long result.
So I think the most natural way to do the "2 or more for extra
security" is to allow us to use a very long hash. It does not
help to allow an object to be referred to with any of these 2 or
more hashes at the same time.
* If employing 2 or more hashes by combining into one may enhance
the security, that is wonderful. But we want to discourage
people from inventing their own combinations left and right and
end up fragmenting the world. If a project that begins with
SHA-1 only naming is forked to two (or more) and each fork uses
different hashes, merging them back will become harder than
necessary unless you support all these hashes forks used.
Having said all that, the way to figure out the hash used in the way
we spell the object name may not be the best place to discourage
people from using random hashes of their choice. But I think we
want to avoid doing something that would actively encourage
fragmentation.
^ permalink raw reply
* Re: [PATCH] submodule init: warn about falling back to a local path
From: Stefan Beller @ 2017-02-24 20:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, git@vger.kernel.org, Philip Oakley, Shawn Pearce
In-Reply-To: <xmqqlgsv1guq.fsf@gitster.mtv.corp.google.com>
On Fri, Feb 24, 2017 at 12:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> When a submodule is initialized, the config variable 'submodule.<name>.url'
>> is set depending on the value of the same variable in the .gitmodules
>> file. When the URL indicates to be relative, then the url is computed
>> relative to its default remote. The default remote cannot be determined
>> accurately in all cases, such that it falls back to 'origin'.
>>
>> The 'origin' remote may not exist, though. In that case we give up looking
>> for a suitable remote and we'll just assume it to be a local relative path.
>
> IOW we keep the .url to be relative, the same as the original one we
> took from .gitmodules?
Well that is one way to say that. Another way is:
If we cannot construct a URL based on the given relative URL, we
demote the relative URL to be a relative PATH and resolve that instead.
> That sounds like a sensible thing to do and
> I agree it makes sense to warn when it happens.
ok.
>
>> @@ -118,18 +122,22 @@ too (and can also report changes to a submodule's work tree).
>>
>> init [--] [<path>...]::
>> Initialize the submodules recorded in the index (which were
>> - added and committed elsewhere) by copying submodule
>> - names and urls from .gitmodules to .git/config.
>> - Optional <path> arguments limit which submodules will be initialized.
>> - It will also copy the value of `submodule.$name.update` into
>> - .git/config.
>> - The key used in .git/config is `submodule.$name.url`.
>> - This command does not alter existing information in .git/config.
>> - You can then customize the submodule clone URLs in .git/config
>> - for your local setup and proceed to `git submodule update`;
>> - you can also just use `git submodule update --init` without
>> - the explicit 'init' step if you do not intend to customize
>> - any submodule locations.
>> + added and committed elsewhere) by copying `submodule.$name.url`
>> + from .gitmodules to .git/config, resolving relative urls to be
>> + relative to the default remote.
>
> I read this as "copying..., resolving relative to the default remote
> (if exists)." A reader would wonder what happens if the default
> remote does not exist---don't we want to describe what happens in
> that case, like, "recording . (the current repository) as the
> upstream" or something?
eh, a better approach is s/copying/<something else>/
We will resolve the relative URL no matter what. It's just that
we may end up with an absolute path instead of an absolute URL.
>
>> ++
>> +Optional <path> arguments limit which submodules will be initialized.
>> +If no path is specified all submodules are initialized.
>
> Perhaps s/ all submodules/,&/?
ok
Will reroll, once I have found a better wording.
^ permalink raw reply
* Re: [PATCH] submodule init: warn about falling back to a local path
From: Junio C Hamano @ 2017-02-24 20:19 UTC (permalink / raw)
To: Stefan Beller; +Cc: j6t, git, philipoakley, sop
In-Reply-To: <20170224182237.3696-1-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> When a submodule is initialized, the config variable 'submodule.<name>.url'
> is set depending on the value of the same variable in the .gitmodules
> file. When the URL indicates to be relative, then the url is computed
> relative to its default remote. The default remote cannot be determined
> accurately in all cases, such that it falls back to 'origin'.
>
> The 'origin' remote may not exist, though. In that case we give up looking
> for a suitable remote and we'll just assume it to be a local relative path.
IOW we keep the .url to be relative, the same as the original one we
took from .gitmodules? That sounds like a sensible thing to do and
I agree it makes sense to warn when it happens.
> <repository> is the URL of the new submodule's origin repository.
> This may be either an absolute URL, or (if it begins with ./
> -or ../), the location relative to the superproject's origin
> +or ../), the location relative to the superproject's default remote
> repository (Please note that to specify a repository 'foo.git'
> which is located right next to a superproject 'bar.git', you'll
> have to use '../foo.git' instead of './foo.git' - as one might expect
> when following the rules for relative URLs - because the evaluation
> of relative URLs in Git is identical to that of relative directories).
> -If the superproject doesn't have an origin configured
> ++
> +The default remote is the remote of the remote tracking branch
> +of the current branch. If no such remote tracking branch exists or
> +the HEAD is detached, "origin" is assumed to be the default remote.
> +If the superproject doesn't have a default remote configured
OK.
> @@ -118,18 +122,22 @@ too (and can also report changes to a submodule's work tree).
>
> init [--] [<path>...]::
> Initialize the submodules recorded in the index (which were
> - added and committed elsewhere) by copying submodule
> - names and urls from .gitmodules to .git/config.
> - Optional <path> arguments limit which submodules will be initialized.
> - It will also copy the value of `submodule.$name.update` into
> - .git/config.
> - The key used in .git/config is `submodule.$name.url`.
> - This command does not alter existing information in .git/config.
> - You can then customize the submodule clone URLs in .git/config
> - for your local setup and proceed to `git submodule update`;
> - you can also just use `git submodule update --init` without
> - the explicit 'init' step if you do not intend to customize
> - any submodule locations.
> + added and committed elsewhere) by copying `submodule.$name.url`
> + from .gitmodules to .git/config, resolving relative urls to be
> + relative to the default remote.
I read this as "copying..., resolving relative to the default remote
(if exists)." A reader would wonder what happens if the default
remote does not exist---don't we want to describe what happens in
that case, like, "recording . (the current repository) as the
upstream" or something?
> ++
> +Optional <path> arguments limit which submodules will be initialized.
> +If no path is specified all submodules are initialized.
Perhaps s/ all submodules/,&/?
> deinit [-f|--force] (--all|[--] <path>...)::
> Unregister the given submodules, i.e. remove the whole
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> index 899dc334e3..15a5430c00 100644
> --- a/builtin/submodule--helper.c
> +++ b/builtin/submodule--helper.c
> @@ -356,12 +356,10 @@ static void init_submodule(const char *path, const char *prefix, int quiet)
> strbuf_addf(&remotesb, "remote.%s.url", remote);
> free(remote);
>
> - if (git_config_get_string(remotesb.buf, &remoteurl))
> - /*
> - * The repository is its own
> - * authoritative upstream
> - */
> + if (git_config_get_string(remotesb.buf, &remoteurl)) {
> + warning(_("could not lookup configuration '%s'. Assuming this repository is its own authoritative upstream."), remotesb.buf);
Sounds sensible (it might be a bit too long but it should be OK).
> remoteurl = xgetcwd();
> + }
> relurl = relative_url(remoteurl, url, NULL);
> strbuf_release(&remotesb);
> free(remoteurl);
Thanks.
^ permalink raw reply
* Re: SHA1 collisions found
From: ankostis @ 2017-02-24 20:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Stefan Beller, David Lang, Ian Jackson, Joey Hess,
git@vger.kernel.org
In-Reply-To: <xmqq7f4f4cqg.fsf@gitster.mtv.corp.google.com>
On 24 February 2017 at 20:20, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>>> you are inviting people to start using
>>>
>>> md5,54ddf8d47340e048166c45f439ce65fd
>>>
>>> as object names.
>>
>> which might even be okay for specific subsets of operations.
>> (e.g. all local work including staging things, making local "fixup" commits)
>>
>> The addressing scheme should not be too hardcoded, we should rather
>> treat it similar to the cipher schemes in pgp. The additional complexity that
>> we have is the longevity of existence of things, though.
>
> The not-so-well-hidden agenda was exactly that we _SHOULD_ not
> mimick PGP. They do not have a requirement to encourage everybody
> to use the same thing because each message is encrypted/signed
> independently, i.e. they do not have to chain things like we do.
But there is a scenario where supporting more hashes, in parallel, is
beneficial:
Let's assume that git is retroffited to always support the "default"
SHA-3, but support additionally more hash-funcs.
If in the future SHA-3 also gets defeated, it would be highly unlikely
that the same math would also break e.g. Blake.
So certain high-profile repos might choose for extra security 2 or more hashes.
Apologies if I'm misusing the list,
Kostis
^ permalink raw reply
* Re: SHA1 collisions found
From: Junio C Hamano @ 2017-02-24 20:05 UTC (permalink / raw)
To: Stefan Beller; +Cc: David Lang, Ian Jackson, Joey Hess, git@vger.kernel.org
In-Reply-To: <xmqq7f4f4cqg.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> The not-so-well-hidden agenda was exactly that we _SHOULD_ not
> mimick PGP. They do not have a requirement to encourage everybody
> to use the same thing because each message is encrypted/signed
> independently, i.e. they do not have to chain things like we do.
To put it less succinctly, PGP does not have incentive to encourage
everybody to converge to the same. They can afford to say "You can
use whatever you among your circles agree to use and the rest of the
world won't care". If two groups that have used different ones later
meet, both of them can switch to a common one from that point forward,
but their past exchanges won't affect the future.
You cannot say the same thing for Git. Once you decide to merge two
histories from two camps, which may have originated from the same
codebase but then decided to use two different ones while they were
forked, you'd be forced to support all three forever. We have a lot
stronger incentive to discourage fragmentation.
^ permalink raw reply
* Re: fatal error when diffing changed symlinks
From: Junio C Hamano @ 2017-02-24 19:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Christophe Macabiau
In-Reply-To: <xmqqshn34gsh.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
>> cd /tmp
>> mkdir a
>> cd a
>> git init
>> touch b
>> ln -s b c
>> git add .
>> git commit -m 'first'
>> touch d
>> rm c
>> ln -s d c
>> git difftool --dir-diff
>
> A slightly worse is that the upcoming Git will ship with a rewritten
> "difftool" that makes the above sequence segfault.
The culprit seems to be these lines in run_dir_diff():
if (S_ISLNK(lmode)) {
char *content = read_sha1_file(loid.hash, &type, &size);
add_left_or_right(&symlinks2, src_path, content, 0);
free(content);
}
if (S_ISLNK(rmode)) {
char *content = read_sha1_file(roid.hash, &type, &size);
add_left_or_right(&symlinks2, dst_path, content, 1);
free(content);
}
When viewing a working tree file, oid.hash could be 0{40} and
read_sha1_file() is not the right function to use to obtain the
contents.
Both of these two need to pay attention to 0{40}, I think, as the
user may be running "difftool -R --dir-diff" in which case the
working tree would appear in the left hand side instead.
I didn't follow the codepath for regular files closely, but the code
that follows the above excerpt does quite different things to lstate
and rstate, which makes me suspect that the code is not prepared to
see "-R"(everse) diff (and I further suspect that these issues were
inherited from the original scripted Porcelain).
^ permalink raw reply
* Re: [PATCH v6 1/1] config: add conditional include
From: Ramsay Jones @ 2017-02-24 19:48 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy, git
Cc: Junio C Hamano, Jeff King, sschuberth, Matthieu Moy
In-Reply-To: <20170224131425.32409-2-pclouds@gmail.com>
On 24/02/17 13:14, Nguyễn Thái Ngọc Duy wrote:
[snip]
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Documentation/config.txt | 61 +++++++++++++++++++++++++++++
> config.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++
> t/t1305-config-include.sh | 56 +++++++++++++++++++++++++++
> 3 files changed, 214 insertions(+)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 015346c417..6c0cd2a273 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -91,6 +91,56 @@ found at the location of the include directive. If the value of the
> relative to the configuration file in which the include directive was
> found. See below for examples.
>
> +Conditional includes
> +~~~~~~~~~~~~~~~~~~~~
> +
> +You can include one config file from another conditionally by setting
> +a `includeIf.<condition>.path` variable to the name of the file to be
> +included. The variable's value is treated the same way as `include.path`.
> +
> +The condition starts with a keyword followed by a colon and some data
> +whose format and meaning depends on the keyword. Supported keywords
> +are:
> +
> +`gitdir`::
> +
> + The data that follows the keyword `gitdir:` is used as a glob
> + pattern. If the location of the .git directory match the
> + pattern, the include condition is met.
> ++
> +The .git location which may be auto-discovered, or come from
> +`$GIT_DIR` environment variable. If the repository auto discovered via
> +a .git file (e.g. from submodules, or a linked worktree), the .git
> +location would be the final location, not where the .git file is.
> ++
> +The pattern can contain standard globbing wildcards and two additional
> +ones, `**/` and `/**`, that can match multiple path components. Please
> +refer to linkgit:gitignore[5] for details. For convenience:
> +
> + * If the pattern starts with `~/`, `~` will be substituted with the
> + content of the environment variable `HOME`.
> +
> + * If the pattern starts with `./`, it is replaced with the directory
> + containing the current config file.
> +
> + * If the pattern does not start with either `~/`, `./` or `/`, `**/`
> + will be automatically prepended. For example, the pattern `foo/bar`
> + becomes `**/foo/bar` and would match `/any/path/to/foo/bar`.
> +
> + * If the pattern ends with `/`, `**` will be automatically added. For
> + example, the pattern `foo/` becomes `foo/**`. In other words, it
> + matches "foo" and everything inside, recursively.
> +
> +`gitdir/i`::
> + This is the same as `gitdir` except that matching is done
> + case-insensitively (e.g. on case-insensitive file sytems)
> +
> +A few more notes on matching with `gitdir` and `gitdir/i`:
> +
> + * Symlinks in `$GIT_DIR` are not resolved before matching.
> +
> + * Note that "../" is not special and will match literally, which is
> + unlikely what you want.
>
> Example
> ~~~~~~~
> @@ -119,6 +169,17 @@ Example
> path = foo ; expand "foo" relative to the current file
> path = ~/foo ; expand "foo" in your `$HOME` directory
>
> + ; include if $GIT_DIR is /path/to/foo/.git
> + [include-if "gitdir:/path/to/foo/.git"]
s/include-if/includeIf/
> + path = /path/to/foo.inc
> +
> + ; include for all repositories inside /path/to/group
> + [include-if "gitdir:/path/to/group/"]
ditto
> + path = /path/to/foo.inc
> +
> + ; include for all repositories inside $HOME/to/group
> + [include-if "gitdir:~/to/group/"]
ditto
ATB,
Ramsay Jones
^ permalink raw reply
* [ANNOUNCE] Git v2.12.0
From: Junio C Hamano @ 2017-02-24 19:28 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest feature release Git v2.12.0 is now available at the
usual places. It is comprised of 517 non-merge commits since
v2.11.0, contributed by 80 people, 24 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.12.0'
tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.11.0 are as follows.
Welcome to the Git development community!
Alan Davies, Andreas Krey, Cornelius Weig, Damien Regad, David
Pursehouse, Denton Liu, George Vanburgh, Igor Kushnir, Jack
Bates, Joachim Jablon, Jordi Mas, Kristoffer Haugsbakk, Kyle
Meyer, Luis Ressel, Lukas Puehringer, Markus Hitter, Peter Law,
Rasmus Villemoes, Rogier Goossens, Stefan Dotterweich, Steven
Penny, Vinicius Kursancew, Vladimir Panteleev, and Wolfram Sang.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
마누엘, Alexander Shopov, Alex Henrie, Anthony Ramine,
Beat Bolli, Brandon Williams, brian m. carlson, Changwoo Ryu,
Chris Packham, Christian Couder, David Aguilar, David Turner,
Dennis Kaarsemaker, Dimitriy Ryazantcev, Elia Pinto, Eric Wong,
Grégoire Paris, Heiko Voigt, Jacob Keller, Jean-Noel Avila,
Jeff Hostetler, Jeff King, Jiang Xin, Johannes Schindelin,
Johannes Sixt, Jonathan Tan, Junio C Hamano, Kyle J. McKay,
Lars Schneider, Linus Torvalds, Luke Diamand, Matt McCutchen,
Max Kirillov, Mike Hommey, Nguyễn Thái Ngọc Duy, Patrick
Steinhardt, Paul Mackerras, Peter Krefting, Philip Oakley,
Pranit Bauva, Ralf Thielow, Ramsay Jones, Ray Chen, René
Scharfe, Richard Hansen, Santiago Torres, Satoshi Yasushima,
Stefan Beller, Stephan Beyer, SZEDER Gábor, Thomas Gummerer,
Torsten Bögershausen, Trần Ngọc Quân, Vasco Almeida,
Vegard Nossum, and Vitaly "_Vi" Shukela.
----------------------------------------------------------------
Git 2.12 Release Notes
======================
Backward compatibility notes.
* Use of an empty string that is used for 'everything matches' is
still warned and Git asks users to use a more explicit '.' for that
instead. The hope is that existing users will not mind this
change, and eventually the warning can be turned into a hard error,
upgrading the deprecation into removal of this (mis)feature. That
is not scheduled to happen in the upcoming release (yet).
* The historical argument order "git merge <msg> HEAD <commit>..."
has been deprecated for quite some time, and will be removed in a
future release.
* An ancient script "git relink" has been removed.
Updates since v2.11
-------------------
UI, Workflows & Features
* Various updates to "git p4".
* "git p4" didn't interact with the internal of .git directory
correctly in the modern "git-worktree"-enabled world.
* "git branch --list" and friends learned "--ignore-case" option to
optionally sort branches and tags case insensitively.
* In addition to %(subject), %(body), "log --pretty=format:..."
learned a new placeholder %(trailers).
* "git rebase" learned "--quit" option, which allows a user to
remove the metadata left by an earlier "git rebase" that was
manually aborted without using "git rebase --abort".
* "git clone --reference $there --recurse-submodules $super" has been
taught to guess repositories usable as references for submodules of
$super that are embedded in $there while making a clone of the
superproject borrow objects from $there; extend the mechanism to
also allow submodules of these submodules to borrow repositories
embedded in these clones of the submodules embedded in the clone of
the superproject.
* Porcelain scripts written in Perl are getting internationalized.
* "git merge --continue" has been added as a synonym to "git commit"
to conclude a merge that has stopped due to conflicts.
* Finer-grained control of what protocols are allowed for transports
during clone/fetch/push have been enabled via a new configuration
mechanism.
* "git shortlog" learned "--committer" option to group commits by
committer, instead of author.
* GitLFS integration with "git p4" has been updated.
* The isatty() emulation for Windows has been updated to eradicate
the previous hack that depended on internals of (older) MSVC
runtime.
* Some platforms no longer understand "latin-1" that is still seen in
the wild in e-mail headers; replace them with "iso-8859-1" that is
more widely known when conversion fails from/to it.
* "git grep" has been taught to optionally recurse into submodules.
* "git rm" used to refuse to remove a submodule when it has its own
git repository embedded in its working tree. It learned to move
the repository away to $GIT_DIR/modules/ of the superproject
instead, and allow the submodule to be deleted (as long as there
will be no loss of local modifications, that is).
* A recent updates to "git p4" was not usable for older p4 but it
could be made to work with minimum changes. Do so.
* "git diff" learned diff.interHunkContext configuration variable
that gives the default value for its --inter-hunk-context option.
* The prereleaseSuffix feature of version comparison that is used in
"git tag -l" did not correctly when two or more prereleases for the
same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2
are there and the code needs to compare 2.0-beta1 and 2.0-beta2).
* "git submodule push" learned "--recurse-submodules=only option to
push submodules out without pushing the top-level superproject.
* "git tag" and "git verify-tag" learned to put GPG verification
status in their "--format=<placeholders>" output format.
* An ancient repository conversion tool left in contrib/ has been
removed.
* "git show-ref HEAD" used with "--verify" because the user is not
interested in seeing refs/remotes/origin/HEAD, and used with
"--head" because the user does not want HEAD to be filtered out,
i.e. "git show-ref --head --verify HEAD", did not work as expected.
* "git submodule add" used to be confused and refused to add a
locally created repository; users can now use "--force" option
to add them.
(merge 619acfc78c sb/submodule-add-force later to maint).
* Some people feel the default set of colors used by "git log --graph"
rather limiting. A mechanism to customize the set of colors has
been introduced.
* "git read-tree" and its underlying unpack_trees() machinery learned
to report problematic paths prefixed with the --super-prefix option.
* When a submodule "A", which has another submodule "B" nested within
it, is "absorbed" into the top-level superproject, the inner
submodule "B" used to be left in a strange state. The logic to
adjust the .git pointers in these submodules has been corrected.
* The user can specify a custom update method that is run when
"submodule update" updates an already checked out submodule. This
was ignored when checking the submodule out for the first time and
we instead always just checked out the commit that is bound to the
path in the superproject's index.
* The command line completion (in contrib/) learned that
"git diff --submodule=" can take "diff" as a recently added option.
* The "core.logAllRefUpdates" that used to be boolean has been
enhanced to take 'always' as well, to record ref updates to refs
other than the ones that are expected to be updated (i.e. branches,
remote-tracking branches and notes).
* Comes with more command line completion (in contrib/) for recently
introduced options.
Performance, Internal Implementation, Development Support etc.
* Commands that operate on a log message and add lines to the trailer
blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and
"commit -s", have been taught to use the logic of and share the
code with "git interpret-trailer".
* The default Travis-CI configuration specifies newer P4 and GitLFS.
* The "fast hash" that had disastrous performance issues in some
corner cases has been retired from the internal diff.
* The character width table has been updated to match Unicode 9.0
* Update the procedure to generate "tags" for developer support.
* The codeflow of setting NOATIME and CLOEXEC on file descriptors Git
opens has been simplified.
* "git diff" and its family had two experimental heuristics to shift
the contents of a hunk to make the patch easier to read. One of
them turns out to be better than the other, so leave only the
"--indent-heuristic" option and remove the other one.
* A new submodule helper "git submodule embedgitdirs" to make it
easier to move embedded .git/ directory for submodules in a
superproject to .git/modules/ (and point the latter with the former
that is turned into a "gitdir:" file) has been added.
* "git push \\server\share\dir" has recently regressed and then
fixed. A test has retroactively been added for this breakage.
* Build updates for Cygwin.
* The implementation of "real_path()" was to go there with chdir(2)
and call getcwd(3), but this obviously wouldn't be usable in a
threaded environment. Rewrite it to manually resolve relative
paths including symbolic links in path components.
* Adjust documentation to help AsciiDoctor render better while not
breaking the rendering done by AsciiDoc.
* The sequencer machinery has been further enhanced so that a later
set of patches can start using it to reimplement "rebase -i".
* Update the definition of the MacOSX test environment used by
TravisCI.
* Rewrite a scripted porcelain "git difftool" in C.
* "make -C t failed" will now run only the tests that failed in the
previous run. This is usable only when prove is not use, and gives
a useless error message when run after "make clean", but otherwise
is serviceable.
* "uchar [40]" to "struct object_id" conversion continues.
Also contains various documentation updates and code clean-ups.
Fixes since v2.10
-----------------
Unless otherwise noted, all the fixes since v2.9 in the maintenance
track are contained in this release (see the maintenance releases'
notes for details).
* We often decide if a session is interactive by checking if the
standard I/O streams are connected to a TTY, but isatty() that
comes with Windows incorrectly returned true if it is used on NUL
(i.e. an equivalent to /dev/null). This has been fixed.
* "git svn" did not work well with path components that are "0", and
some configuration variable it uses were not documented.
* "git rev-parse --symbolic" failed with a more recent notation like
"HEAD^-1" and "HEAD^!".
* An empty directory in a working tree that can simply be nuked used
to interfere while merging or cherry-picking a change to create a
submodule directory there, which has been fixed..
* The code in "git push" to compute if any commit being pushed in the
superproject binds a commit in a submodule that hasn't been pushed
out was overly inefficient, making it unusable even for a small
project that does not have any submodule but have a reasonable
number of refs.
* "git push --dry-run --recurse-submodule=on-demand" wasn't
"--dry-run" in the submodules.
* The output from "git worktree list" was made in readdir() order,
and was unstable.
* mergetool.<tool>.trustExitCode configuration variable did not apply
to built-in tools, but now it does.
* "git p4" LFS support was broken when LFS stores an empty blob.
* A corner case in merge-recursive regression that crept in
during 2.10 development cycle has been fixed.
* Transport with dumb http can be fooled into following foreign URLs
that the end user does not intend to, especially with the server
side redirects and http-alternates mechanism, which can lead to
security issues. Tighten the redirection and make it more obvious
to the end user when it happens.
* Update the error messages from the dumb-http client when it fails
to obtain loose objects; we used to give sensible error message
only upon 404 but we now forbid unexpected redirects that needs to
be reported with something sensible.
* When diff.renames configuration is on (and with Git 2.9 and later,
it is enabled by default, which made it worse), "git stash"
misbehaved if a file is removed and another file with a very
similar content is added.
* "git diff --no-index" did not take "--no-abbrev" option.
* "git difftool --dir-diff" had a minor regression when started from
a subdirectory, which has been fixed.
* "git commit --allow-empty --only" (no pathspec) with dirty index
ought to be an acceptable way to create a new commit that does not
change any paths, but it was forbidden, perhaps because nobody
needed it so far.
* Git 2.11 had a minor regression in "merge --ff-only" that competed
with another process that simultanously attempted to update the
index. We used to explain what went wrong with an error message,
but the new code silently failed. The error message has been
resurrected.
* A pathname that begins with "//" or "\\" on Windows is special but
path normalization logic was unaware of it.
* "git pull --rebase", when there is no new commits on our side since
we forked from the upstream, should be able to fast-forward without
invoking "git rebase", but it didn't.
* The way to specify hotkeys to "xxdiff" that is used by "git
mergetool" has been modernized to match recent versions of xxdiff.
* Unlike "git am --abort", "git cherry-pick --abort" moved HEAD back
to where cherry-pick started while picking multiple changes, when
the cherry-pick stopped to ask for help from the user, and the user
did "git reset --hard" to a different commit in order to re-attempt
the operation.
* Code cleanup in shallow boundary computation.
* A recent update to receive-pack to make it easier to drop garbage
objects made it clear that GIT_ALTERNATE_OBJECT_DIRECTORIES cannot
have a pathname with a colon in it (no surprise!), and this in turn
made it impossible to push into a repository at such a path. This
has been fixed by introducing a quoting mechanism used when
appending such a path to the colon-separated list.
* The function usage_msg_opt() has been updated to say "fatal:"
before the custom message programs give, when they want to die
with a message about wrong command line options followed by the
standard usage string.
* "git index-pack --stdin" needs an access to an existing repository,
but "git index-pack file.pack" to generate an .idx file that
corresponds to a packfile does not.
* Fix for NDEBUG builds.
* A lazy "git push" without refspec did not internally use a fully
specified refspec to perform 'current', 'simple', or 'upstream'
push, causing unnecessary "ambiguous ref" errors.
* "git p4" misbehaved when swapping a directory and a symbolic link.
* Even though an fix was attempted in Git 2.9.3 days, but running
"git difftool --dir-diff" from a subdirectory never worked. This
has been fixed.
* "git p4" that tracks multile p4 paths imported a single changelist
that touches files in these multiple paths as one commit, followed
by many empty commits. This has been fixed.
* A potential but unlikely buffer overflow in Windows port has been
fixed.
* When the http server gives an incomplete response to a smart-http
rpc call, it could lead to client waiting for a full response that
will never come. Teach the client side to notice this condition
and abort the transfer.
* Compression setting for producing packfiles were spread across
three codepaths, one of which did not honor any configuration.
Unify these so that all of them honor core.compression and
pack.compression variables the same way.
* "git fast-import" sometimes mishandled while rebalancing notes
tree, which has been fixed.
* Recent update to the default abbreviation length that auto-scales
lacked documentation update, which has been corrected.
* Leakage of lockfiles in the config subsystem has been fixed.
* It is natural that "git gc --auto" may not attempt to pack
everything into a single pack, and there is no point in warning
when the user has configured the system to use the pack bitmap,
leading to disabling further "gc".
* "git archive" did not read the standard configuration files, and
failed to notice a file that is marked as binary via the userdiff
driver configuration.
* "git blame --porcelain" misidentified the "previous" <commit, path>
pair (aka "source") when contents came from two or more files.
* "git rebase -i" with a recent update started showing an incorrect
count when squashing more than 10 commits.
* "git <cmd> @{push}" on a detached HEAD used to segfault; it has
been corrected to error out with a message.
* Running "git add a/b" when "a" is a submodule correctly errored
out, but without a meaningful error message.
(merge 2d81c48fa7 sb/pathspec-errors later to maint).
* Typing ^C to pager, which usually does not kill it, killed Git and
took the pager down as a collateral damage in certain process-tree
structure. This has been fixed.
* "git mergetool" without any pathspec on the command line that is
run from a subdirectory became no-op in Git v2.11 by mistake, which
has been fixed.
* Retire long unused/unmaintained gitview from the contrib/ area.
(merge 3120925c25 sb/remove-gitview later to maint).
* Tighten a test to avoid mistaking an extended ERE regexp engine as
a PRE regexp engine.
* An error message with an ASCII control character like '\r' in it
can alter the message to hide its early part, which is problematic
when a remote side gives such an error message that the local side
will relay with a "remote: " prefix.
(merge f290089879 jk/vreport-sanitize later to maint).
* "git fsck" inspects loose objects more carefully now.
(merge cce044df7f jk/loose-object-fsck later to maint).
* A crashing bug introduced in v2.11 timeframe has been found (it is
triggerable only in fast-import) and fixed.
(merge abd5a00268 jk/clear-delta-base-cache-fix later to maint).
* With an anticipatory tweak for remotes defined in ~/.gitconfig
(e.g. "remote.origin.prune" set to true, even though there may or
may not actually be "origin" remote defined in a particular Git
repository), "git remote rename" and other commands misinterpreted
and behaved as if such a non-existing remote actually existed.
(merge e459b073fb js/remote-rename-with-half-configured-remote later to maint).
* A few codepaths had to rely on a global variable when sorting
elements of an array because sort(3) API does not allow extra data
to be passed to the comparison function. Use qsort_s() when
natively available, and a fallback implementation of it when not,
to eliminate the need, which is a prerequisite for making the
codepath reentrant.
* "git fsck --connectivity-check" was not working at all.
(merge a2b22854bd jk/fsck-connectivity-check-fix later to maint).
* After starting "git rebase -i", which first opens the user's editor
to edit the series of patches to apply, but before saving the
contents of that file, "git status" failed to show the current
state (i.e. you are in an interactive rebase session, but you have
applied no steps yet) correctly.
(merge df9ded4984 js/status-pre-rebase-i later to maint).
* Test tweak for FreeBSD where /usr/bin/unzip is unsuitable to run
our tests but /usr/local/bin/unzip is usable.
(merge d98b2c5fce js/unzip-in-usr-bin-workaround later to maint).
* "git p4" did not work well with multiple git-p4.mapUser entries on
Windows.
(merge c3c2b05776 gv/mingw-p4-mapuser later to maint).
* "git help" enumerates executable files in $PATH; the implementation
of "is this file executable?" on Windows has been optimized.
(merge c755015f79 hv/mingw-help-is-executable later to maint).
* Test tweaks for those who have default ACL in their git source tree
that interfere with the umask test.
(merge d549d21307 mm/reset-facl-before-umask-test later to maint).
* Names of the various hook scripts must be spelled exactly, but on
Windows, an .exe binary must be named with .exe suffix; notice
$GIT_DIR/hooks/<hookname>.exe as a valid <hookname> hook.
(merge 235be51fbe js/mingw-hooks-with-exe-suffix later to maint).
* Asciidoctor, an alternative reimplementation of AsciiDoc, still
needs some changes to work with documents meant to be formatted
with AsciiDoc. "make USE_ASCIIDOCTOR=YesPlease" to use it out of
the box to document our pages is getting closer to reality.
* Correct command line completion (in contrib/) on "git svn"
(merge 2cbad17642 ew/complete-svn-authorship-options later to maint).
* Incorrect usage help message for "git worktree prune" has been fixed.
(merge 2488dcab22 ps/worktree-prune-help-fix later to maint).
* Adjust a perf test to new world order where commands that do
require a repository are really strict about having a repository.
(merge c86000c1a7 rs/p5302-create-repositories-before-tests later to maint).
* "git log --graph" did not work well with "--name-only", even though
other forms of "diff" output were handled correctly.
(merge f5022b5fed jk/log-graph-name-only later to maint).
* The push-options given via the "--push-options" option were not
passed through to external remote helpers such as "smart HTTP" that
are invoked via the transport helper.
* The documentation explained what "git stash" does to the working
tree (after stashing away the local changes) in terms of "reset
--hard", which was exposing an unnecessary implementation detail.
(merge 20a7e06172 tg/stash-doc-cleanup later to maint).
* When "git p4" imports changelist that removes paths, it failed to
convert pathnames when the p4 used encoding different from the one
used on the Git side. This has been corrected.
(merge a8b05162e8 ls/p4-path-encoding later to maint).
* A new coccinelle rule that catches a check of !pointer before the
pointer is free(3)d, which most likely is a bug.
(merge ec6cd14c7a rs/cocci-check-free-only-null later to maint).
* "ls-files" run with pathspec has been micro-optimized to avoid
having to memmove(3) unnecessary bytes.
(merge 96f6d3f61a rs/ls-files-partial-optim later to maint).
* A hotfix for a topic already in 'master'.
(merge a4d92d579f js/mingw-isatty later to maint).
* Other minor doc, test and build updates and code cleanups.
(merge f2627d9b19 sb/submodule-config-cleanup later to maint).
(merge 384f1a167b sb/unpack-trees-cleanup later to maint).
(merge 874444b704 rh/diff-orderfile-doc later to maint).
(merge eafd5d9483 cw/doc-sign-off later to maint).
(merge 0aaad415bc rs/absolute-pathdup later to maint).
(merge 4432dd6b5b rs/receive-pack-cleanup later to maint).
(merge 540a398e9c sg/mailmap-self later to maint).
(merge 209df269a6 nd/rev-list-all-includes-HEAD-doc later to maint).
(merge 941b9c5270 sb/doc-unify-bottom later to maint).
(merge 2aaf37b62c jk/doc-remote-helpers-markup-fix later to maint).
(merge e91461b332 jk/doc-submodule-markup-fix later to maint).
(merge 8ab9740d9f dp/submodule-doc-markup-fix later to maint).
(merge 0838cbc22f jk/tempfile-ferror-fclose-confusion later to maint).
(merge 115a40add6 dr/doc-check-ref-format-normalize later to maint).
(merge 133f0a299d gp/document-dotfiles-in-templates-are-not-copied later to maint).
(merge 2b35a9f4c7 bc/blame-doc-fix later to maint).
(merge 7e82388024 ps/doc-gc-aggressive-depth-update later to maint).
(merge 9993a7c5f1 bc/worktree-doc-fix-detached later to maint).
(merge e519eccdf4 rt/align-add-i-help-text later to maint).
^ 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