* Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]
From: Jacob Keller @ 2016-09-19 23:57 UTC (permalink / raw)
To: Josh Triplett
Cc: Jeff King, Junio C Hamano, Andrew Donnellan, Git mailing list
In-Reply-To: <20160919235550.GC29421@cloud>
On Mon, Sep 19, 2016 at 4:55 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> On Mon, Sep 19, 2016 at 04:46:06PM -0700, Jacob Keller wrote:
>> On Mon, Sep 19, 2016 at 4:40 PM, Josh Triplett <josh@joshtriplett.org> wrote:
>> > On Mon, Sep 19, 2016 at 04:34:35PM -0700, Jeff King wrote:
>> >> As far as your patch goes, I'd be OK with defining:
>> >>
>> >> --rfc::
>> >> Pretend as if `--subject-prefix='RFC PATCH'` was given.
>> >>
>>
>> Would:
>>
>> Shorthand for `--subject-prefix='RFC PATCH'`
>>
>> be a better reading? I feel like using "pretend" is a bit weird here.
>
> My patch used "Alias for"; if you prefer "Shorthand for" I'm
> indifferent. :)
Alias seems fine to me.
Thanks,
Jake
^ permalink raw reply
* Re: .git directory tree as tar-file
From: Anatoly Borodin @ 2016-09-20 0:48 UTC (permalink / raw)
To: git
In-Reply-To: <1474317076.23916.6.camel@gmail.com>
Hi Martin,
if multiple small loose files are the problem, this could be interesting
for you:
https://git-scm.com/docs/git-gc
This command is run automatically from time to time, and you can
configure it or run manually.
PS To see how bad the situation is, you can use
https://git-scm.com/docs/git-count-objects
--
Mit freundlichen Grüßen,
Anatoly Borodin
^ permalink raw reply
* Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]
From: Jeff King @ 2016-09-20 1:37 UTC (permalink / raw)
To: Josh Triplett; +Cc: Junio C Hamano, Andrew Donnellan, git
In-Reply-To: <20160919234022.GA29421@cloud>
On Mon, Sep 19, 2016 at 04:40:22PM -0700, Josh Triplett wrote:
> > - there are a non-trivial number of patches for other projects (JGIT,
> > EGIT, StGit, etc). This is somewhat unique to git, where we discuss
> > a lot of related projects on the list. But I wonder if other
> > projects would use subsystems in a similar way (though I guess for
> > the kernel, there are separate subsystems lists, so the "to" or "cc"
> > header becomes the more interesting tag).
>
> The kernel mostly uses "[PATCH] subsystem: ...". Occasionally I see
> "[PATCH somegitrepo ...] ..." when it's necessary to explicitly say
> whose git repo the patch needs to go through, but that's pretty rare.
We do both. "foo: blah" is for subsystem "foo" of Git itself, but
all-caps "JGIT PATCH" is "this is not even for Git". I don't know that
the kernel really has an equivalent.
-Peff
^ permalink raw reply
* Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]
From: Jeff King @ 2016-09-20 1:37 UTC (permalink / raw)
To: Josh Triplett
Cc: Jacob Keller, Junio C Hamano, Andrew Donnellan, Git mailing list
In-Reply-To: <20160919235550.GC29421@cloud>
On Mon, Sep 19, 2016 at 04:55:50PM -0700, Josh Triplett wrote:
> On Mon, Sep 19, 2016 at 04:46:06PM -0700, Jacob Keller wrote:
> > On Mon, Sep 19, 2016 at 4:40 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> > > On Mon, Sep 19, 2016 at 04:34:35PM -0700, Jeff King wrote:
> > >> As far as your patch goes, I'd be OK with defining:
> > >>
> > >> --rfc::
> > >> Pretend as if `--subject-prefix='RFC PATCH'` was given.
> > >>
> >
> > Would:
> >
> > Shorthand for `--subject-prefix='RFC PATCH'`
> >
> > be a better reading? I feel like using "pretend" is a bit weird here.
>
> My patch used "Alias for"; if you prefer "Shorthand for" I'm
> indifferent. :)
Or maybe "Act as if...".
-Peff
^ permalink raw reply
* Re: Bug: pager.<cmd> doesn't work well with editors
From: Jeff King @ 2016-09-20 1:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anatoly Borodin, git
In-Reply-To: <xmqqh99bho7a.fsf@gitster.mtv.corp.google.com>
On Mon, Sep 19, 2016 at 09:03:05AM -0700, Junio C Hamano wrote:
> Anatoly Borodin <anatoly.borodin@gmail.com> writes:
>
> >> I think, the pagination should be turned off when the editor is being
> >> called.
>
> This is a fun one. IIRC, we decide to spawn a pager and run our
> output via pipe thru it fairly early, even before we figure out
> which subcommand is being run (especially if you do "git -p
> subcommand"), which by definition is way before we know if that
> subcommand wants to let the user edit things with the editor.
Right. Once the pager is spawned, it is too late to change things (even
if we spawned the editor directed to /dev/tty, it would be racily
competing for input with the pager).
And this isn't really limited to the editor. It's more _annoying_ with
the editor, but really "pager.tag" does not make any sense to set right
now, because it is handled outside of the "tag" command entirely, and
doesn't know what mode the tag command will be running in. So it's
_also_ the wrong thing to do with "git tag foo", which doesn't run an
editor (but you don't tend to notice if you use "less -F" because the
pager just quits immediately).
So you really only want to page tag-listing (and the same for branch,
config, etc). A long time ago I had a patch to add "pager.tag.list", and
the tag command would decide whether and how to page after realizing it
was in listing mode. Looks like I did send it to the list:
http://public-inbox.org/git/20111007144438.GA30318@sigill.intra.peff.net/
though I think there are some rough edges (like handling "git stash
list").
I also wonder if there are any commands that actually have more than one
sub-command. So another option would be to teach the main git.c a
blacklist of "do not respect pager config" commands (like tag), and then
tag itself could decide to respect pager.tag at the right moment.
I think that makes things worse for a third-party command, though; we
cannot know whether a script "git-foobar" dropped into the $PATH would
like us to respect pager.foobar or if it would prefer to decide itself
later.
-Peff
^ permalink raw reply
* Re: [PATCH] mailinfo: unescape quoted-pair in header fields
From: Jeff King @ 2016-09-20 3:57 UTC (permalink / raw)
To: Kevin Daudt; +Cc: git, Swift Geek, Junio C Hamano
In-Reply-To: <20160919105133.GA10901@ikke.info>
On Mon, Sep 19, 2016 at 12:51:33PM +0200, Kevin Daudt wrote:
> > I didn't look in the RFC. Is:
> >
> > From: my \"name\" <foo@example.com>
> >
> > really the same as:
> >
> > From: "my \\\"name\\\"" <foo@example.com>
> >
> > ? That seems weird, but I think it may be that the former is simply
> > bogus (you are not supposed to use backslashes outside of the quoted
> > section at all).
>
> Correct, the quoted-pair (escape sequence) can only occur in a quoted
> string or a comment. Even more so, the display name *needs* to be quoted
> when consisting of more then one word according to the RFC.
Hmm. So, I guess a follow-up question is: what would it be OK to do if
we see a quoted-pair outside of quotes? If the top one above violates
the RFC, it seems like stripping the backslashes would be a reasonable
outcome.
So if that's the case, do we actually need to care if we see any
parenthesized comments? I think we should just leave comments in place
either way, so syntactically they are only interesting insofar as we
replace quoted pairs or not.
IOW, I wonder if:
while ((c = *in++)) {
switch (c) {
case '\\':
if (!*in)
return 0; /* ignore trailing backslash */
/* quoted pair */
strbuf_addch(out, *in++);
break;
case '"':
/*
* This may be starting or ending a quoted section,
* but we do not care whether we are in such a section.
* We _do_ need to remove the quotes, though, as they
* are syntactic.
*/
break;
default:
/*
* Anything else is a normal character we keep. These
* _might_ be violating the RFC if they are magic
* characters outside of a quoted section, but we'd
* rather be liberal and pass them through.
*/
strbuf_addch(out, c);
break;
}
}
would work. I certainly do not mind following the RFC more closely, but
AFAICT the very simple code above gives a pretty forgiving outcome.
> > This is obviously getting pretty silly, but if we are going to follow
> > the RFC, I think you actually have to do a recursive parse, and keep
> > track of an arbitrary depth of context.
> >
> > I dunno. This method probably covers most cases in practice, and it's
> > easy to reason about.
>
> The problem is, how do you differentiate between nested comments, and
> escaped braces within a comment after one run?
I'm not sure what you mean. Escaped characters are always handled first
in your loop. Can you give an example (although if you agree with what I
wrote above, it may not be worth discussing further)?
-Peff
^ permalink raw reply
* Re: [PATCH v2 1/2] t5100-mailinfo: replace common path prefix with variable
From: Jeff King @ 2016-09-20 3:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kevin Daudt, git, Swift Geek
In-Reply-To: <xmqqzin3d1zs.fsf@gitster.mtv.corp.google.com>
On Mon, Sep 19, 2016 at 02:16:23PM -0700, Junio C Hamano wrote:
> Kevin Daudt <me@ikke.info> writes:
>
> > Many tests need to store data in a file, and repeat the same pattern to
> > refer to that path:
> >
> > "$TEST_DATA"/t5100/
>
> That obviously is a typo of
>
> "$TEST_DIRECTORY/t5100"
>
> It is a good change, even though I would have chosen a name
> that is a bit more descriptive than "$DATA".
The name "$DATA" was my suggestion. I was shooting for something short
since this is used a lot and is really a script-local variable (I'd have
kept it lowercase to indicate that, but maybe that is just me).
Something like "$root" would also work. I dunno.
> > - test_cmp "$TEST_DIRECTORY"/t5100/msg$mo msg$mo &&
> > - test_cmp "$TEST_DIRECTORY"/t5100/patch$mo patch$mo &&
> > - test_cmp "$TEST_DIRECTORY"/t5100/info$mo info$mo
> > + test_cmp "$DATA"/msg$mo msg$mo &&
> > + test_cmp "$DATA"/patch$mo patch$mo &&
> > + test_cmp "$DATA"/info$mo info$mo
>
> make me wonder why we don't quote the whole thing, i.e.
>
> test_cmp "$TEST_DATA/info$mo" "info$mo"
>
> as leaving $mo part unquoted forces reader to wonder if it is our
> deliberate attempt to allow shell $IFS in $mo and have the argument
> split when that happens, which can be avoided if we quoted more
> explicitly.
>
> Perhaps we'd leave that as a low-hanging fruit for future people.
Yeah, I agree that quoting the whole thing makes it more obvious (though
I guess quoting the second info$mo does add two characters).
-Peff
^ permalink raw reply
* [PATCH v3] format-patch: Add --rfc for the common case of [RFC PATCH]
From: Josh Triplett @ 2016-09-20 4:23 UTC (permalink / raw)
To: git; +Cc: Andrew Donnellan, Jeff King
This provides a shorter and more convenient alias for
--subject-prefix='RFC PATCH'.
Includes documentation in the format-patch manpage, and a new test
covering --rfc.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
---
v3:
- Fix an error message referring to --subject-prefix
- Expand the acronym "RFC"
v2:
- Add documentation to the format-patch manpage
- Call subject_prefix_callback rather than reimplementing it
- Update test to move expectations inside
Documentation/git-format-patch.txt | 8 +++++++-
builtin/log.c | 10 +++++++++-
t/t4014-format-patch.sh | 9 +++++++++
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 9624c84..9b200b3 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -19,7 +19,8 @@ SYNOPSIS
[--start-number <n>] [--numbered-files]
[--in-reply-to=Message-Id] [--suffix=.<sfx>]
[--ignore-if-in-upstream]
- [--subject-prefix=Subject-Prefix] [(--reroll-count|-v) <n>]
+ [--rfc] [--subject-prefix=Subject-Prefix]
+ [(--reroll-count|-v) <n>]
[--to=<email>] [--cc=<email>]
[--[no-]cover-letter] [--quiet] [--notes[=<ref>]]
[<common diff options>]
@@ -172,6 +173,11 @@ will want to ensure that threading is disabled for `git send-email`.
allows for useful naming of a patch series, and can be
combined with the `--numbered` option.
+--rfc::
+ Alias for `--subject-prefix="RFC PATCH"`. RFC means "Request For
+ Comments"; use this when sending an experimental patch for
+ discussion rather than application.
+
-v <n>::
--reroll-count=<n>::
Mark the series as the <n>-th iteration of the topic. The
diff --git a/builtin/log.c b/builtin/log.c
index 92dc34d..c657900 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1112,6 +1112,11 @@ static int subject_prefix_callback(const struct option *opt, const char *arg,
return 0;
}
+static int rfc_callback(const struct option *opt, const char *arg, int unset)
+{
+ return subject_prefix_callback(opt, "RFC PATCH", unset);
+}
+
static int numbered_cmdline_opt = 0;
static int numbered_callback(const struct option *opt, const char *arg,
@@ -1419,6 +1424,9 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
N_("start numbering patches at <n> instead of 1")),
OPT_INTEGER('v', "reroll-count", &reroll_count,
N_("mark the series as Nth re-roll")),
+ { OPTION_CALLBACK, 0, "rfc", &rev, NULL,
+ N_("Use [RFC PATCH] instead of [PATCH]"),
+ PARSE_OPT_NOARG | PARSE_OPT_NONEG, rfc_callback },
{ OPTION_CALLBACK, 0, "subject-prefix", &rev, N_("prefix"),
N_("Use [<prefix>] instead of [PATCH]"),
PARSE_OPT_NONEG, subject_prefix_callback },
@@ -1557,7 +1565,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
if (numbered && keep_subject)
die (_("-n and -k are mutually exclusive."));
if (keep_subject && subject_prefix)
- die (_("--subject-prefix and -k are mutually exclusive."));
+ die (_("--subject-prefix/--rfc and -k are mutually exclusive."));
rev.preserve_subject = keep_subject;
argc = setup_revisions(argc, argv, &rev, &s_r_opt);
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index b0579dd..ed4d3c2 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -1073,6 +1073,15 @@ test_expect_success 'empty subject prefix does not have extra space' '
test_cmp expect actual
'
+test_expect_success '--rfc' '
+ cat >expect <<-\EOF &&
+ Subject: [RFC PATCH 1/1] header with . in it
+ EOF
+ git format-patch -n -1 --stdout --rfc >patch &&
+ grep ^Subject: patch >actual &&
+ test_cmp expect actual
+'
+
test_expect_success '--from=ident notices bogus ident' '
test_must_fail git format-patch -1 --stdout --from=foo >patch
'
base-commit: 6ebdac1bab966b720d776aa43ca188fe378b1f4b
--
git-series 0.8.10
^ permalink raw reply related
* Re: [PATCH v2 2/2] mailinfo: unescape quoted-pair in header fields
From: Jeff King @ 2016-09-20 4:28 UTC (permalink / raw)
To: Kevin Daudt; +Cc: git, Swift Geek, Junio C Hamano
In-Reply-To: <20160919185440.18234-3-me@ikke.info>
On Mon, Sep 19, 2016 at 08:54:40PM +0200, Kevin Daudt wrote:
> diff --git a/t/t5100/comment.expect b/t/t5100/comment.expect
> new file mode 100644
> index 0000000..1197e76
> --- /dev/null
> +++ b/t/t5100/comment.expect
> @@ -0,0 +1,5 @@
> +Author: A U Thor (this is a comment (really))
Hmm. I don't see any recursion in your parsing, so after the first ")"
our escape_context would be 0 again, right? So a more tricky test is:
Author: A U Thor (this is a comment (really) with \(quoted\) pairs)
We are still inside "ctext" when we hit those quoted pairs, and they
should be unquoted, but your code would not do so (unless we go the
route of simply unquoting pairs everywhere).
I think your parser would have to follow the BNF more closely with a
recursive descent parser, like:
const char *parse_comment(const char *in, struct strbuf *out)
{
size_t orig_out = out->len;
if ((in = parse_char('(', in, out))) &&
(in = parse_ccontent(in, out)) &&
(in = parse_char(')', in, out))))
return in;
strbuf_setlen(out, orig_out);
return NULL;
}
const char *parse_ccontent(const char *in, struct strbuf *out)
{
while (*in && *in != ')') {
const char *next;
if ((next = parse_quoted_pair(in, out)) ||
(next = parse_comment(in, out)) ||
(next = parse_ctext(in, out))) {
in = next;
continue;
}
}
/*
* if "in" is NUL here we have an unclosed comment; but we'll
* just silently ignore and accept it
*/
return in;
}
const char *parse_char(char c, const char *in, struct strbuf *out)
{
if (*in != c)
return NULL;
strbuf_addch(out, c);
return in + 1;
}
You can probably guess at the implementation of parse_quoted_pair(),
parse_ctext(), etc (and naturally, the above is completely untested and
probably has some bugs in it).
In a former life (back when it was still rfc822!) I remember
implementing a similar parser, which I think was in turn based on the
cclient code in pine. It's not _too_ hard to get it all right based on
the BNF in the RFC, but as you can see it's a bit tedious. And I'm not
convinced we actually need it to be completely right for our purposes.
We really are looking for a single address, with the email in "<>" and
the name as everything before that, but de-quoted.
-Peff
^ permalink raw reply
* Re: [PATCH v3] format-patch: Add --rfc for the common case of [RFC PATCH]
From: Jeff King @ 2016-09-20 4:29 UTC (permalink / raw)
To: Josh Triplett; +Cc: git, Andrew Donnellan
In-Reply-To: <501a6bfb2a70f44f080b2f119e4503ccbf88f639.1474330487.git-series.josh@joshtriplett.org>
On Mon, Sep 19, 2016 at 09:23:25PM -0700, Josh Triplett wrote:
> This provides a shorter and more convenient alias for
> --subject-prefix='RFC PATCH'.
>
> Includes documentation in the format-patch manpage, and a new test
> covering --rfc.
>
> Signed-off-by: Josh Triplett <josh@joshtriplett.org>
> ---
> v3:
> - Fix an error message referring to --subject-prefix
> - Expand the acronym "RFC"
This looks fine to me. Thanks.
-Peff
^ permalink raw reply
* [PATCH tg/add-chmod+x-fix 1/2] t3700-add: create subdirectory gently
From: Johannes Sixt @ 2016-09-20 6:16 UTC (permalink / raw)
To: Thomas Gummerer; +Cc: Git Mailing List
The subdirectory 'sub' is created early in the test file. Later, a test
case removes it during its clean-up actions. However, this test case is
protected by POSIXPERM. Consequently, 'sub' remains when the POSIXPERM
prerequisite is not satisfied. Later, a recently introduced test case
creates 'sub' again. Use -p with mkdir so that it does not fail if 'sub'
already exists.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
t/t3700-add.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 0a962a6..16ab2da 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -380,7 +380,7 @@ test_expect_success 'no file status change if no pathspec is given' '
'
test_expect_success 'no file status change if no pathspec is given in subdir' '
- mkdir sub &&
+ mkdir -p sub &&
(
cd sub &&
>sub-foo1 &&
--
2.10.0.85.gea34e30
^ permalink raw reply related
* [PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM
From: Johannes Sixt @ 2016-09-20 6:18 UTC (permalink / raw)
To: Thomas Gummerer; +Cc: Git Mailing List
In-Reply-To: <cee3c784-8f03-c524-2f67-d35cb3755a41@kdbg.org>
A recently introduced test checks the result of 'git status' after
setting the executable bit on a file. This check does not yield the
expected result when the filesystem does not support the executable bit
(and core.filemode is false). Skip the test case.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
I am surprised that add --chmod=+x changes only the index, but not
the file on disk!?!
t/t3700-add.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index 16ab2da..13e0dd2 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -361,7 +361,7 @@ test_expect_success 'git add --chmod=[+-]x changes index with already added file
test_mode_in_index 100644 xfoo3
'
-test_expect_success 'file status is changed after git add --chmod=+x' '
+test_expect_success POSIXPERM 'file status is changed after git add --chmod=+x' '
echo "AM foo4" >expected &&
echo foo >foo4 &&
git add foo4 &&
--
2.10.0.85.gea34e30
^ permalink raw reply related
* Re: [PATCH v3 0/8] Better heuristics make prettier diffs
From: Michael Haggerty @ 2016-09-20 6:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Ramsay Jones, René Scharfe, Stefan Beller, Jeff King,
Jakub Narębski, Jacob Keller
In-Reply-To: <xmqqintrg5pq.fsf@gitster.mtv.corp.google.com>
On 09/19/2016 07:27 PM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>
>>> On 09/08/2016 01:25 AM, Junio C Hamano wrote:
>>>> I'd move it temporarily to t4061 with a separate SQUASH??? at the
>>>> tip for now, as I am running out of time today.
>>>
>>> I didn't realize you were waiting for an ACK. Yes, it's totally OK to
>>> rename the test.
>>
>> I actually wasn't asking for an Ack.
>>
>> As the issue was in the one that is buried a few commits from the
>> tip, and there is a later one that adds more tests to it, I didn't
>> find enough energy to rename the new file in a buried commit and
>> then adjust the patch later updates it, I was hoping that you'd
>> reroll to save me effort, rather than forcing me to do the rebase
>> myself ;-).
>
> Now I did, so no need to resend (unless you have changes other than
> the renaming of the test script, that is).
Thanks for taking care of this.
> Let's move it down to 'next' soonish.
Yes, it would be good to get feedback early enough in the cycle that we
can make a final decision about which diff heuristics should be used by
default and whether/what UI to implement for switching between them.
Michael
^ permalink raw reply
* Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]
From: Jacob Keller @ 2016-09-20 6:50 UTC (permalink / raw)
To: Jeff King
Cc: Josh Triplett, Junio C Hamano, Andrew Donnellan, Git mailing list
In-Reply-To: <20160920013704.7hk2creytmfrla6h@sigill.intra.peff.net>
On Mon, Sep 19, 2016 at 6:37 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Sep 19, 2016 at 04:40:22PM -0700, Josh Triplett wrote:
>
>> > - there are a non-trivial number of patches for other projects (JGIT,
>> > EGIT, StGit, etc). This is somewhat unique to git, where we discuss
>> > a lot of related projects on the list. But I wonder if other
>> > projects would use subsystems in a similar way (though I guess for
>> > the kernel, there are separate subsystems lists, so the "to" or "cc"
>> > header becomes the more interesting tag).
>>
>> The kernel mostly uses "[PATCH] subsystem: ...". Occasionally I see
>> "[PATCH somegitrepo ...] ..." when it's necessary to explicitly say
>> whose git repo the patch needs to go through, but that's pretty rare.
>
> We do both. "foo: blah" is for subsystem "foo" of Git itself, but
> all-caps "JGIT PATCH" is "this is not even for Git". I don't know that
> the kernel really has an equivalent.
>
> -Peff
[net] and [net-next] are for the *tree* not the subsystem of the tree.
net: also means the networking subsystem, but it's different you might
have a new feature and say
[net-next PATCH v2] net: my awesome new feature.
Thanks,
Jake
^ permalink raw reply
* [PATCH] git-check-ref-format.txt: fixup documentation
From: Elia Pinto @ 2016-09-20 7:33 UTC (permalink / raw)
To: git; +Cc: Elia Pinto
die is not a standard shell function. Use
a different shell code for the example.
Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
---
Documentation/git-check-ref-format.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 91a3622..8611a99 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -118,8 +118,8 @@ $ git check-ref-format --branch @{-1}
* Determine the reference name to use for a new branch:
+
------------
-$ ref=$(git check-ref-format --normalize "refs/heads/$newbranch") ||
-die "we do not like '$newbranch' as a branch name."
+$ ref=$(git check-ref-format --normalize "refs/heads/$newbranch")||
+{ echo "we do not like '$newbranch' as a branch name." >&2 ; exit 1 ; }
------------
GIT
--
2.10.0.645.gc4ba6eb
^ permalink raw reply related
* Limitiations of git rebase --preserve-merges --interactive
From: Stefan Haller @ 2016-09-20 8:46 UTC (permalink / raw)
To: git
The BUGS section of the git-rebase manpage says that editing or
rewording commits "should work fine", but attempts to reorder commits
usually don't do what you want.
I'd like to know more about what does or doesn't work. For example, will
squashing commits work? (I.e. using the "fixup" or "squash" commands in
the todo sheet.)
Will dropping commits work?
Does it make sense to insert "exec" commands, or will they run at
arbitrary times?
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ permalink raw reply
* Re: Re: Homebrew and Git
From: Heiko Voigt @ 2016-09-20 11:07 UTC (permalink / raw)
To: Jonas Thiel; +Cc: git
In-Reply-To: <20160920110228.GA64315@book.hvoigt.net>
On Tue, Sep 20, 2016 at 01:02:28PM +0200, Heiko Voigt wrote:
> Hi,
>
> On Sun, Sep 18, 2016 at 05:50:28PM +0200, Jonas Thiel wrote:
> > A while ago I have described my problem with Homebrew at the following
> > GitHub channel
> > (https://github.com/Homebrew/homebrew-core/issues/2970). In the
> > meanwhile, I believe that I my problem with Homebrew is based on an
> > issues with my Git. I have found the attached Git Crash reports on my
> > Mac and because I am not familiar with reading/analysing Crash
> > Reports, it would be great if someone could give me some feedback on
> > it.
> >
> > If you have any question, please do not hesitate to contact me.
>
> From your crash reports I see that git is apparently crashing in a
> strchr() call from within ident_default_email() which is a function that
> tries to assemble a name and email to put into your commits.
BTW, here is the callstack inlined from the crashreport:
bsystem_platform.dylib 0x00007fff840db41c _platform_strchr$VARIANT$Haswell + 28
1 git 0x000000010ba1d3f4 ident_default_email + 801
2 git 0x000000010ba1d68f fmt_ident + 66
3 git 0x000000010ba4b495 files_log_ref_write + 175
4 git 0x000000010ba4b0a6 commit_ref_update + 106
5 git 0x000000010ba4c3a8 ref_transaction_commit + 468
6 git 0x000000010b994dd8 s_update_ref + 271
7 git 0x000000010b994556 fetch_refs + 1969
8 git 0x000000010b9935f2 fetch_one + 1913
9 git 0x000000010b992bc4 cmd_fetch + 549
10 git 0x000000010b9666c4 handle_builtin + 478
11 git 0x000000010b96602f main + 376
12 libdyld.dylib 0x00007fff834ef5ad start + 1
Maybe someone else has an idea what might be causing this...
Cheers Heiko
^ permalink raw reply
* Re: Homebrew and Git
From: Heiko Voigt @ 2016-09-20 11:02 UTC (permalink / raw)
To: Jonas Thiel; +Cc: git
In-Reply-To: <trinity-9c8f1bd1-d6be-48f3-8575-03be09bd1243-1474213828361@3capp-gmx-bs53>
Hi,
On Sun, Sep 18, 2016 at 05:50:28PM +0200, Jonas Thiel wrote:
> A while ago I have described my problem with Homebrew at the following
> GitHub channel
> (https://github.com/Homebrew/homebrew-core/issues/2970). In the
> meanwhile, I believe that I my problem with Homebrew is based on an
> issues with my Git. I have found the attached Git Crash reports on my
> Mac and because I am not familiar with reading/analysing Crash
> Reports, it would be great if someone could give me some feedback on
> it.
>
> If you have any question, please do not hesitate to contact me.
From your crash reports I see that git is apparently crashing in a
strchr() call from within ident_default_email() which is a function that
tries to assemble a name and email to put into your commits.
Can you post us the output of
hostname -f
and
whoami
?
Since it seems you are using an Apple git can you also give us the
output of
git version
Since it seems that Apple is compiling its own git (and not publishing
the changes they made conveniently via git). Have you tried
installing a vanilla git via homebrew and seeing whether that also
produces the issue?
In your bugreport you are talking about modifications you do to your
system after which the issue occurred. I would suggest to exactly find
out which step lead to git crashing (if it actually is the issue). First
to identify an issue we need something that is reproduceable.
Cheers Heiko
^ permalink raw reply
* Re: git-gui, was Re: [PATCH v2 6/6] git-gui: Update Japanese information
From: Vasco Almeida @ 2016-09-20 13:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqeg4ujq24.fsf@gitster.mtv.corp.google.com>
Hi Junio Hamano,
I have sent some git-gui patches on May this year and I think it will
add value to accepted them at some point:
git-gui: i18n stuff and small fixes
<1462704778-4722-1-git-send-email-vascomalmeida@sapo.pt>
http://www.mail-archive.com/git@vger.kernel.org/msg92780.html
git-gui: l10n: add Portuguese translation
<1462550802-20601-1-git-send-email-vascomalmeida@sapo.pt>
http://www.mail-archive.com/git@vger.kernel.org/msg92611.html
There is the gitk Portuguese translation also, but that is out of the
topic. For reference:
gitk: Makefile: create install bin directory
<1462470392-19991-1-git-send-email-vascomalmeida@sapo.pt>
http://www.mail-archive.com/git@vger.kernel.org/msg92474.html
gitk: Add Portuguese translation
<1462996893-24341-1-git-send-email-vascomalmeida@sapo.pt>
http://www.mail-archive.com/git@vger.kernel.org/msg93176.html
Thank you.
^ permalink raw reply
* v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name
From: Steffen Nurpmeso @ 2016-09-20 16:23 UTC (permalink / raw)
To: git
Hello again,
yah, sorry, i'm back again..
I try to find a way to find the name of the current branch in an
automated way, because i need to ensure that a commit happens on
it and no other branch. Now the problem arises that the commit
ref at the time of that commit maybe shared in between several
different branches, but no more thereafter, of course:
?0[steffen@wales ]$ git branch|grep '^*'
* stable/v14.9
?0[steffen@wales ]$ git name-rev --name-only HEAD
stable/v14.8
Is there another way except looking into .git/HEAD or using sed(1)
on the output of `branch' to find the right name?
Thank you.
Ciao!
--steffen
^ permalink raw reply
* Re: [PATCH v2] ls-files: add pathspec matching for submodules
From: Brandon Williams @ 2016-09-20 16:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <xmqqh99bcw6m.fsf@gitster.mtv.corp.google.com>
On Mon, Sep 19, 2016 at 4:21 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> As the previous one that used a wrong (sorry) argument is not even
> in 'next' yet, let's pretend that it never happened. It is OK to
> still keep it and this patch as two separate steps, i.e. a topic
> with two patches in it.
>
> That means that this patch will become 2/2 of a series, and 1/2 is
> rerolled to use submodule_prefix from the get-go, without ever
> introducing output_path_prefix variable, so that many of the above
> lines we won't have to review in 2/2.
Ah ok. Would you like me to resend the first patch with the desired
change then?
>
>> + /*
>> + * Pass in the original pathspec args. The submodule will be
>> + * responsible for prepending the 'submodule_prefix' prior to comparing
>> + * against the pathspec for matches.
>> + */
>
> Good.
>
>> + argv_array_push(&cp.args, "--");
>> + for (i = 0; i < pathspec.nr; ++i)
>> + argv_array_push(&cp.args, pathspec.items[i].original);
>> +
>
> Please prefer post-increment i++ over pre-increment ++i when writing
> a for(;;) loop, unless there is a strong reason not to (familiarlity
> in C++ is not a good reason).
I had a compiler instructor drill into my head that ++i in a for loop
was faster historically
since it wouldn't have to create a temporary value. Of course now a days there
probably isn't much (or any) difference between the two. If post-fix
operators are the
norm in git code then I can try to remember to use them :)
>> +
>> + if (item->flags & PATHSPEC_ONESTAR) {
>> + return WM_MATCH;
>> + } else if (item->magic & PATHSPEC_GLOB) {
>> + return wildmatch(pattern, string,
>> + WM_PATHNAME |
>> + (item->magic & PATHSPEC_ICASE ?
>> + WM_CASEFOLD : 0),
>> + NULL);
>
> Isn't this last one overly tight? I am wondering about a scenario
> where you have a submodule at "sub/" in the superproject, and "sub/"
> has a "file" at the top of its working tree. And you do:
>
> git ls-files --recurse-submodules ':(glob)??b/fi?e'
>
> at the top of the superproject. The "pattern" would be '??b/fi?e"
> while string would be 'sub', and wildmatch() would not like it, but
> there is no way for this caller to append anything to 'sub' before
> making this call, as it hasn't looked into what paths appear in the
> submodule repository (and it should not want to). And I think we
> would want it to recurse to find sub/file. IOW, this looks like a
> false negative we must avoid in this function. As we cannot afford
> to check if anything that matches 'fi?e' is in the index file of the
> submodule repository, we shouldn't try to match 'fi?e' portion of
> the given pathspec pattern.
good point. Let me think about this some more.
^ permalink raw reply
* 2.10.0: git log --oneline prints gpg signatures in 4 lines
From: Leandro Lucarella @ 2016-09-20 15:09 UTC (permalink / raw)
To: git
Hi, starting from 2.10.0 I noticed that when using git log --oneline,
if commits are signed with GPG, now the signatures are printed too, and
it takes 3 lines for the signature information + 1 line for the title
of the commit, so suddenly --oneline became --fourline :)
Is this really intended?
--
Leandro Lucarella
Technical Development Lead
Sociomantic Labs GmbH <http://www.sociomantic.com>
^ permalink raw reply
* [PATCH v3 0/3] handle multiline in-body headers
From: Jonathan Tan @ 2016-09-20 17:17 UTC (permalink / raw)
To: git; +Cc: Jonathan Tan, gitster
In-Reply-To: <cover.1474319086.git.jonathantanmy@google.com>
Changes since v2:
o Removed utf8 translation before scissors line check in
check_inbody_header (I was thinking of support for encodings like
UTF-16, but I guess those don't work with the current reencode_string
anyway since it uses strlen internally)
With the above change, it is actually no longer necessary to make
is_scissors_line take plain char * (the second patch) - I think that
that patch still improves the code, but let me know if you want me to
remove it from this patch set.
Jonathan Tan (3):
mailinfo: separate in-body header processing
mailinfo: make is_scissors_line take plain char *
mailinfo: handle in-body header continuations
mailinfo.c | 116 +++++++++++++++++++++++++----------
mailinfo.h | 1 +
t/t4150-am.sh | 23 +++++++
t/t5100-mailinfo.sh | 2 +-
t/t5100/info0018 | 5 ++
t/t5100/info0018--no-inbody-headers | 5 ++
t/t5100/msg0015 | 2 -
t/t5100/msg0018 | 2 +
t/t5100/msg0018--no-inbody-headers | 8 +++
t/t5100/patch0018 | 6 ++
t/t5100/patch0018--no-inbody-headers | 6 ++
t/t5100/sample.mbox | 19 ++++++
12 files changed, 159 insertions(+), 36 deletions(-)
create mode 100644 t/t5100/info0018
create mode 100644 t/t5100/info0018--no-inbody-headers
create mode 100644 t/t5100/msg0018
create mode 100644 t/t5100/msg0018--no-inbody-headers
create mode 100644 t/t5100/patch0018
create mode 100644 t/t5100/patch0018--no-inbody-headers
--
2.10.0.rc2.20.g5b18e70
^ permalink raw reply
* [PATCH v3 1/3] mailinfo: separate in-body header processing
From: Jonathan Tan @ 2016-09-20 17:17 UTC (permalink / raw)
To: git; +Cc: Jonathan Tan, gitster
In-Reply-To: <cover.1474391594.git.jonathantanmy@google.com>
The check_header function contains logic specific to in-body headers,
although it is invoked during both the processing of actual headers and
in-body headers. Separate out the in-body header part into its own
function.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
---
mailinfo.c | 33 +++++++++++++++++----------------
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/mailinfo.c b/mailinfo.c
index e19abe3..0c4738a 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -495,21 +495,6 @@ static int check_header(struct mailinfo *mi,
goto check_header_out;
}
- /* for inbody stuff */
- if (starts_with(line->buf, ">From") && isspace(line->buf[5])) {
- ret = is_format_patch_separator(line->buf + 1, line->len - 1);
- goto check_header_out;
- }
- if (starts_with(line->buf, "[PATCH]") && isspace(line->buf[7])) {
- for (i = 0; header[i]; i++) {
- if (!strcmp("Subject", header[i])) {
- handle_header(&hdr_data[i], line);
- ret = 1;
- goto check_header_out;
- }
- }
- }
-
check_header_out:
strbuf_release(&sb);
return ret;
@@ -623,6 +608,22 @@ static int is_scissors_line(const struct strbuf *line)
gap * 2 < perforation);
}
+static int check_inbody_header(struct mailinfo *mi, const struct strbuf *line)
+{
+ if (starts_with(line->buf, ">From") && isspace(line->buf[5]))
+ return is_format_patch_separator(line->buf + 1, line->len - 1);
+ if (starts_with(line->buf, "[PATCH]") && isspace(line->buf[7])) {
+ int i;
+ for (i = 0; header[i]; i++)
+ if (!strcmp("Subject", header[i])) {
+ handle_header(&mi->s_hdr_data[i], line);
+ return 1;
+ }
+ return 0;
+ }
+ return check_header(mi, line, mi->s_hdr_data, 0);
+}
+
static int handle_commit_msg(struct mailinfo *mi, struct strbuf *line)
{
assert(!mi->filter_stage);
@@ -633,7 +634,7 @@ static int handle_commit_msg(struct mailinfo *mi, struct strbuf *line)
}
if (mi->use_inbody_headers && mi->header_stage) {
- mi->header_stage = check_header(mi, line, mi->s_hdr_data, 0);
+ mi->header_stage = check_inbody_header(mi, line);
if (mi->header_stage)
return 0;
} else
--
2.10.0.rc2.20.g5b18e70
^ permalink raw reply related
* [PATCH v3 2/3] mailinfo: make is_scissors_line take plain char *
From: Jonathan Tan @ 2016-09-20 17:17 UTC (permalink / raw)
To: git; +Cc: Jonathan Tan, gitster
In-Reply-To: <cover.1474391594.git.jonathantanmy@google.com>
The is_scissors_line takes a struct strbuf * when a char * would
suffice. Make it take char *.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
---
mailinfo.c | 35 ++++++++++++++++++-----------------
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/mailinfo.c b/mailinfo.c
index 0c4738a..69391aa 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -557,37 +557,35 @@ static inline int patchbreak(const struct strbuf *line)
return 0;
}
-static int is_scissors_line(const struct strbuf *line)
+static int is_scissors_line(const char *line)
{
- size_t i, len = line->len;
+ const char *c;
int scissors = 0, gap = 0;
- int first_nonblank = -1;
- int last_nonblank = 0, visible, perforation = 0, in_perforation = 0;
- const char *buf = line->buf;
+ const char *first_nonblank = NULL, *last_nonblank = NULL;
+ int visible, perforation = 0, in_perforation = 0;
- for (i = 0; i < len; i++) {
- if (isspace(buf[i])) {
+ for (c = line; *c; c++) {
+ if (isspace(*c)) {
if (in_perforation) {
perforation++;
gap++;
}
continue;
}
- last_nonblank = i;
- if (first_nonblank < 0)
- first_nonblank = i;
- if (buf[i] == '-') {
+ last_nonblank = c;
+ if (first_nonblank == NULL)
+ first_nonblank = c;
+ if (*c == '-') {
in_perforation = 1;
perforation++;
continue;
}
- if (i + 1 < len &&
- (!memcmp(buf + i, ">8", 2) || !memcmp(buf + i, "8<", 2) ||
- !memcmp(buf + i, ">%", 2) || !memcmp(buf + i, "%<", 2))) {
+ if ((!memcmp(c, ">8", 2) || !memcmp(c, "8<", 2) ||
+ !memcmp(c, ">%", 2) || !memcmp(c, "%<", 2))) {
in_perforation = 1;
perforation += 2;
scissors += 2;
- i++;
+ c++;
continue;
}
in_perforation = 0;
@@ -602,7 +600,10 @@ static int is_scissors_line(const struct strbuf *line)
* than half of the perforation.
*/
- visible = last_nonblank - first_nonblank + 1;
+ if (first_nonblank && last_nonblank)
+ visible = last_nonblank - first_nonblank + 1;
+ else
+ visible = 0;
return (scissors && 8 <= visible &&
visible < perforation * 3 &&
gap * 2 < perforation);
@@ -647,7 +648,7 @@ static int handle_commit_msg(struct mailinfo *mi, struct strbuf *line)
if (convert_to_utf8(mi, line, mi->charset.buf))
return 0; /* mi->input_error already set */
- if (mi->use_scissors && is_scissors_line(line)) {
+ if (mi->use_scissors && is_scissors_line(line->buf)) {
int i;
strbuf_setlen(&mi->log_message, 0);
--
2.10.0.rc2.20.g5b18e70
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox