* RE: Switching branches not working in a cloned repo
From: Paul Williamson @ 2016-09-19 20:13 UTC (permalink / raw)
To: Jacob Keller; +Cc: git@vger.kernel.org
In-Reply-To: <CA+P7+xqR6i6eieVrEHXMNuVo6yfmRRZqX8RdVAE7y4=xSLLYyA@mail.gmail.com>
-----Original Message-----
From: Jacob Keller [mailto:jacob.keller@gmail.com]
>Try a fresh clone with "git checkout --track origin/web_dev" and then a "git status -v" and let us know what happens. I suspect that older clones have the correct branches already setup for tracking, but the new clone >isn't doing it automatically, so when you run git checkout web_dev you're just creating a new local copy.
Hi Jake, this worked!
Your explanation seems correct - I could still list the remote branches, thanks to the command that Philip suggested, but the linkage between the two was not there by default for some reason. Very strange, I have never seen that happen before.
Anyway, this solution is sound and seems to set everything (history etc) back to how it should be.
Thanks very much for your help!
Paul
^ permalink raw reply
* .git directory tree as tar-file
From: Martin Bammer @ 2016-09-19 20:31 UTC (permalink / raw)
To: git
Hi,
it would be nice to have an option to have a .git.tar instead of the .git
directory tree. This tree quickly gets very big and copy and compare actions
take very long. I've observed that even in small projects with only a few files
the .git tree can contain several thousand entries. Especially when projects are
saved on shares copy and compare actions are getting very slow.
Is such a feature already planned or is there a chance to have such a feature in
the near future?
Best regards,
Martin
^ permalink raw reply
* Re: [PATCH 1/6] i18n: commit: mark message for translation
From: Jean-Noël AVILA @ 2016-09-19 20:34 UTC (permalink / raw)
To: Junio C Hamano
Cc: Vasco Almeida, git, Jiang Xin,
Ævar Arnfjörð Bjarmason
In-Reply-To: <xmqq60prg4gy.fsf@gitster.mtv.corp.google.com>
On lundi 19 septembre 2016 10:54:37 CEST Junio C Hamano wrote:
> I am responding to 1/6, as the series lacked a cover letter, but all
> of them looked good.
>
> Thanks.
Maybe 3/6 would have benefited from some code factorization. But that's ok for
a few more sentences.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]
From: Josh Triplett @ 2016-09-19 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrew Donnellan, git, Jeff King
In-Reply-To: <xmqqa8f3g4pu.fsf@gitster.mtv.corp.google.com>
On Mon, Sep 19, 2016 at 10:49:17AM -0700, Junio C Hamano wrote:
> Andrew Donnellan <andrew.donnellan@au1.ibm.com> writes:
>
> > Sounds good to me. Agreed that "RFC" is essentially the only prefix
> > other than "PATCH" that I see, at least in the kernel.
>
> Around here I think we saw WIP too, and that makes me lean towards
> Peff's earlier suggestion to allow an end-user supplied string in
> front of PATCH, i.e. "-P RFC" => "--subject-prefix='RFC PATCH'",
> even though I understand that those who _ONLY_ care about RFC would
> prefer --rfc (5 keystrokes) over "-P RFC" (6 keystrokes).
I do share the concern raised elsewhere in the thread that adding new
format-patch short options potentially conflicts with diff/rev-list
short options. If you're not worried about that, I'd be happy to add
(and document and test) -P. However, I'd still advocate adding --rfc as
well; it's a common case, and "-P RFC" is actually rather more
keystrokes when you count shifting. :)
There might also be some value in steering people towards "RFC" (since a
WIP is in a way an RFC).
> >> +--rfc::
> >> + Alias for `--subject-prefix="RFC PATCH"`. Use this when
> >> + sending an experimental patch for discussion rather than
> >> + application.
> >
> > Perhaps mention the phrase "Request For Comment" for the benefit of
> > those who aren't familiar ...
>
> Good point.
I'll add that to the documentation in v3.
^ permalink raw reply
* Re: clarification of `rev-list --no-walk ^<rev>`?
From: Philip Oakley @ 2016-09-19 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Git List
In-Reply-To: <xmqqintrek64.fsf@gitster.mtv.corp.google.com>
From: "Junio C Hamano" <gitster@pobox.com>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>>> Philip probably has a
>>> confused notion that "rev-list A..B C..D" is somehow a union of set
>>> A..B and C..D?
>>
>> That wasn't the issue. Though it does beg the question that it's the
>> same as "rev-list D B ^A ^C" isn't it?
>
> If you think it begs the question, then you haven't understood what
> I meant by all of the explanation. Let me repeat:
Apologies. We appear to be having an British/American usage
misunderstanding. Locally, the answer to the begged (rhetorically asked)
question is, as you say, "Yes, they are the same". It was simply confirming
our common understanding.
>
> "A..B C..D" is exactly a short-hand for "^A B ^C D" which is
> the same as ANY permutation like "D B ^A ^C".
>
regards,
Philip
^ permalink raw reply
* Re: .git directory tree as tar-file
From: Jacob Keller @ 2016-09-19 20:53 UTC (permalink / raw)
To: Martin Bammer; +Cc: Git mailing list
In-Reply-To: <1474317076.23916.6.camel@gmail.com>
On Mon, Sep 19, 2016 at 1:31 PM, Martin Bammer <mrbm74@gmail.com> wrote:
> Hi,
>
> it would be nice to have an option to have a .git.tar instead of the .git
> directory tree. This tree quickly gets very big and copy and compare actions
> take very long. I've observed that even in small projects with only a few files
> the .git tree can contain several thousand entries. Especially when projects are
> saved on shares copy and compare actions are getting very slow.
> Is such a feature already planned or is there a chance to have such a feature in
> the near future?
>
> Best regards,
>
It sounds like you're mis-using the git directory and attempting to
share by copying it instead of using any of the protocols designed for
sharing such as local file, ssh, or https.
I don't believe that storing the git via compression is really a good
idea, as many of the operations inside are based on files and we
already try to keep things compressed using various methods already
(pack files)
If you want to actually share a git repository as a bundle, you can
generate such a bundle. See "git help bundle" for more information.
Regards,
Jake
> Martin
>
^ permalink raw reply
* Re: clarification of `rev-list --no-walk ^<rev>`?
From: Junio C Hamano @ 2016-09-19 21:00 UTC (permalink / raw)
To: Philip Oakley; +Cc: Michael J Gruber, Git List
In-Reply-To: <DDC820F0373F4534B4A9D12E8B7B866B@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
>> The "--no-walk" tells the rev-list machinery "I have only positives;
>> do not traverse from them AT ALL but just use these positives".
>> Only under that condition, the order of the positive ends you list
>> on the command line matters.
>
> What does "--do-walk" do ("Overrides a previous --no-walk"), and when
> would it be applied?
Wouldn't
$ git cherry-pick --no-walk --do-walk A
end up walking the history behind A and reproducing the history
since the root commit?
^ permalink raw reply
* Re: [PATCH 1/6] i18n: commit: mark message for translation
From: Junio C Hamano @ 2016-09-19 21:08 UTC (permalink / raw)
To: Jean-Noël AVILA
Cc: Vasco Almeida, git, Jiang Xin,
Ævar Arnfjörð Bjarmason
In-Reply-To: <34292875.FKhN8jTqO5@cayenne>
Jean-Noël AVILA <jn.avila@free.fr> writes:
> Maybe 3/6 would have benefited from some code factorization. But that's ok for
> a few more sentences.
Ah, let me see I understood what you mean. Adding something like
this
static NORETURN void die_want_option(const char *option_name)
{
die(_("option '%s' requires a value"), option_name);
}
and have many of the callers of die() call it would reduce the
number of strings that translators would need to touch.
I agree, but I think we can do that in a later follow-up.
Thanks.
^ permalink raw reply
* [PATCH v2 0/4] handle multiline in-body headers
From: Jonathan Tan @ 2016-09-19 21:08 UTC (permalink / raw)
To: git; +Cc: Jonathan Tan, gitster, peff
This is an iteration of the patch set after the discussion in
<cover.1474047135.git.jonathantanmy@google.com>.
Changes:
o largely rewritten to follow Junio's suggested design (refactor of
check_header to separate out ">From" and "[PATCH]", and an
is_inbody_header function performing an airtight check on whether a
line is an in-body header)
o simpler try_convert_to_utf8 API
o one file of the expected output of t/t5100/*0015 is modified (instead
of the input)
o t/t5100/*0018--no-inbody-headers test files added
o example in commit message improved following Peff's suggestion
Jonathan Tan (4):
mailinfo: separate in-body header processing
mailinfo: refactor to support utf8 decode attempts
mailinfo: make is_scissors_line take plain char *
mailinfo: handle in-body header continuations
mailinfo.c | 164 ++++++++++++++++++++++++++---------
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, 198 insertions(+), 45 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 v2 1/4] mailinfo: separate in-body header processing
From: Jonathan Tan @ 2016-09-19 21:08 UTC (permalink / raw)
To: git; +Cc: Jonathan Tan, gitster, peff
In-Reply-To: <cover.1474319086.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 v2 3/4] mailinfo: make is_scissors_line take plain char *
From: Jonathan Tan @ 2016-09-19 21:08 UTC (permalink / raw)
To: git; +Cc: Jonathan Tan, gitster, peff
In-Reply-To: <cover.1474319086.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 aadad09..1f487df 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -581,37 +581,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;
@@ -626,7 +624,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);
@@ -671,7 +672,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
* [PATCH v2 2/4] mailinfo: refactor to support utf8 decode attempts
From: Jonathan Tan @ 2016-09-19 21:08 UTC (permalink / raw)
To: git; +Cc: Jonathan Tan, gitster, peff
In-Reply-To: <cover.1474319086.git.jonathantanmy@google.com>
mailinfo.c currently has a convert_to_utf8 function that overrides its
argument and prints an error message when the decoding fails. Refactor
it, creating another function that does not override anything and does
not print an error message when the decoding fails. This is to be used
by a subsequent patch.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
---
mailinfo.c | 42 +++++++++++++++++++++++++++++++++---------
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/mailinfo.c b/mailinfo.c
index 0c4738a..aadad09 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -340,23 +340,47 @@ static struct strbuf *decode_b_segment(const struct strbuf *b_seg)
return out;
}
+/*
+ * Attempts to convert line into UTF-8.
+ *
+ * This differs from convert_to_utf8 in that no inputs are overridden, and that
+ * conversion non-success is not considered an error case - mi->input_error is
+ * not set, and no error message is printed.
+ *
+ * If the conversion is unnecessary, returns 1 and stores NULL in result.
+ *
+ * If the conversion is successful, returns 1 and stores the converted string
+ * in result.
+ *
+ * If the conversion is unsuccessful, returns 0 and stores NULL in result.
+ */
+static int try_convert_to_utf8(const struct mailinfo *mi, const char *line,
+ const char *charset, char **result)
+{
+ if (!mi->metainfo_charset || !charset || !*charset ||
+ same_encoding(mi->metainfo_charset, charset)) {
+ *result = NULL;
+ return 1;
+ }
+
+ *result = reencode_string(line, mi->metainfo_charset, charset);
+ return !!*result;
+}
+
+/*
+ * Converts line into UTF-8, setting mi->input_error to -1 upon failure.
+ */
static int convert_to_utf8(struct mailinfo *mi,
struct strbuf *line, const char *charset)
{
char *out;
-
- if (!mi->metainfo_charset || !charset || !*charset)
- return 0;
-
- if (same_encoding(mi->metainfo_charset, charset))
- return 0;
- out = reencode_string(line->buf, mi->metainfo_charset, charset);
- if (!out) {
+ if (!try_convert_to_utf8(mi, line->buf, charset, &out)) {
mi->input_error = -1;
return error("cannot convert from %s to %s",
charset, mi->metainfo_charset);
}
- strbuf_attach(line, out, strlen(out), strlen(out));
+ if (out)
+ strbuf_attach(line, out, strlen(out), strlen(out));
return 0;
}
--
2.10.0.rc2.20.g5b18e70
^ permalink raw reply related
* [PATCH v2 4/4] mailinfo: handle in-body header continuations
From: Jonathan Tan @ 2016-09-19 21:08 UTC (permalink / raw)
To: git; +Cc: Jonathan Tan, gitster, peff
In-Reply-To: <cover.1474319086.git.jonathantanmy@google.com>
Mailinfo currently handles multi-line headers, but it does not handle
multi-line in-body headers. Teach it to handle such headers, for
example, for this input:
From: author <author@example.com>
Date: Fri, 9 Jun 2006 00:44:16 -0700
Subject: a very long
broken line
Subject: another very long
broken line
interpret the in-body subject to be "another very long broken line"
instead of "another very long".
An existing test (t/t5100/msg0015) has an indented line immediately
after an in-body header - it has been modified to reflect the new
functionality.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
---
mailinfo.c | 56 +++++++++++++++++++++++++++++++++++-
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, 131 insertions(+), 4 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
diff --git a/mailinfo.c b/mailinfo.c
index 1f487df..aec3c52 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -524,6 +524,21 @@ static int check_header(struct mailinfo *mi,
return ret;
}
+/*
+ * Returns 1 if the given line or any line beginning with the given line is an
+ * in-body header (that is, check_header will succeed when passed
+ * mi->s_hdr_data).
+ */
+static int is_inbody_header(const struct mailinfo *mi,
+ const struct strbuf *line)
+{
+ int i;
+ for (i = 0; header[i]; i++)
+ if (!mi->s_hdr_data[i] && cmp_header(line, header[i]))
+ return 1;
+ return 0;
+}
+
static void decode_transfer_encoding(struct mailinfo *mi, struct strbuf *line)
{
struct strbuf *ret;
@@ -633,8 +648,39 @@ static int is_scissors_line(const char *line)
gap * 2 < perforation);
}
+static void flush_inbody_header_accum(struct mailinfo *mi)
+{
+ if (!mi->inbody_header_accum.len)
+ return;
+ assert(check_header(mi, &mi->inbody_header_accum, mi->s_hdr_data, 0));
+ strbuf_reset(&mi->inbody_header_accum);
+}
+
static int check_inbody_header(struct mailinfo *mi, const struct strbuf *line)
{
+ if (mi->inbody_header_accum.len &&
+ (line->buf[0] == ' ' || line->buf[0] == '\t')) {
+ char *utf8 = NULL;
+ int is_scissors = mi->use_scissors &&
+ try_convert_to_utf8(mi, line->buf,
+ mi->charset.buf, &utf8) &&
+ is_scissors_line(utf8 ? utf8 : line->buf);
+ free(utf8);
+ if (is_scissors) {
+ /*
+ * This is a scissors line; do not consider this line
+ * as a header continuation line.
+ */
+ flush_inbody_header_accum(mi);
+ return 0;
+ }
+ strbuf_strip_suffix(&mi->inbody_header_accum, "\n");
+ strbuf_addbuf(&mi->inbody_header_accum, line);
+ return 1;
+ }
+
+ flush_inbody_header_accum(mi);
+
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])) {
@@ -646,7 +692,11 @@ static int check_inbody_header(struct mailinfo *mi, const struct strbuf *line)
}
return 0;
}
- return check_header(mi, line, mi->s_hdr_data, 0);
+ if (is_inbody_header(mi, line)) {
+ strbuf_addbuf(&mi->inbody_header_accum, line);
+ return 1;
+ }
+ return 0;
}
static int handle_commit_msg(struct mailinfo *mi, struct strbuf *line)
@@ -912,6 +962,8 @@ static void handle_body(struct mailinfo *mi, struct strbuf *line)
break;
} while (!strbuf_getwholeline(line, mi->input, '\n'));
+ flush_inbody_header_accum(mi);
+
handle_body_out:
strbuf_release(&prev);
}
@@ -1027,6 +1079,7 @@ void setup_mailinfo(struct mailinfo *mi)
strbuf_init(&mi->email, 0);
strbuf_init(&mi->charset, 0);
strbuf_init(&mi->log_message, 0);
+ strbuf_init(&mi->inbody_header_accum, 0);
mi->header_stage = 1;
mi->use_inbody_headers = 1;
mi->content_top = mi->content;
@@ -1040,6 +1093,7 @@ void clear_mailinfo(struct mailinfo *mi)
strbuf_release(&mi->name);
strbuf_release(&mi->email);
strbuf_release(&mi->charset);
+ strbuf_release(&mi->inbody_header_accum);
free(mi->message_id);
for (i = 0; mi->p_hdr_data[i]; i++)
diff --git a/mailinfo.h b/mailinfo.h
index 93776a7..04a2535 100644
--- a/mailinfo.h
+++ b/mailinfo.h
@@ -27,6 +27,7 @@ struct mailinfo {
int patch_lines;
int filter_stage; /* still reading log or are we copying patch? */
int header_stage; /* still checking in-body headers? */
+ struct strbuf inbody_header_accum;
struct strbuf **p_hdr_data;
struct strbuf **s_hdr_data;
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 9ce9424..89a5bac 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -977,4 +977,27 @@ test_expect_success 'am --patch-format=mboxrd handles mboxrd' '
test_cmp msg out
'
+test_expect_success 'am works with multi-line in-body headers' '
+ FORTY="String that has a length of more than forty characters" &&
+ LONG="$FORTY $FORTY" &&
+ rm -fr .git/rebase-apply &&
+ git checkout -f first &&
+ echo one >> file &&
+ git commit -am "$LONG" --author="$LONG <long@example.com>" &&
+ git format-patch --stdout -1 >patch &&
+ # bump from, date, and subject down to in-body header
+ perl -lpe "
+ if (/^From:/) {
+ print \"From: x <x\@example.com>\";
+ print \"Date: Sat, 1 Jan 2000 00:00:00 +0000\";
+ print \"Subject: x\n\";
+ }
+ " patch >msg &&
+ git checkout HEAD^ &&
+ git am msg &&
+ # Ensure that the author and full message are present
+ git cat-file commit HEAD | grep "^author.*long@example.com" &&
+ git cat-file commit HEAD | grep "^$LONG"
+'
+
test_done
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index 1a5a546..e173c33 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -11,7 +11,7 @@ test_expect_success 'split sample box' \
'git mailsplit -o. "$TEST_DIRECTORY"/t5100/sample.mbox >last &&
last=$(cat last) &&
echo total is $last &&
- test $(cat last) = 17'
+ test $(cat last) = 18'
check_mailinfo () {
mail=$1 opt=$2
diff --git a/t/t5100/info0018 b/t/t5100/info0018
new file mode 100644
index 0000000..d53e749
--- /dev/null
+++ b/t/t5100/info0018
@@ -0,0 +1,5 @@
+Author: Another Thor
+Email: a.thor@example.com
+Subject: This one contains a tab and a space
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/info0018--no-inbody-headers b/t/t5100/info0018--no-inbody-headers
new file mode 100644
index 0000000..30b17bd
--- /dev/null
+++ b/t/t5100/info0018--no-inbody-headers
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check multiline inbody headers
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/msg0015 b/t/t5100/msg0015
index 4abb3d5..e69de29 100644
--- a/t/t5100/msg0015
+++ b/t/t5100/msg0015
@@ -1,2 +0,0 @@
- - a list
- - of stuff
diff --git a/t/t5100/msg0018 b/t/t5100/msg0018
new file mode 100644
index 0000000..56de83d
--- /dev/null
+++ b/t/t5100/msg0018
@@ -0,0 +1,2 @@
+a commit message
+
diff --git a/t/t5100/msg0018--no-inbody-headers b/t/t5100/msg0018--no-inbody-headers
new file mode 100644
index 0000000..b1e05d3
--- /dev/null
+++ b/t/t5100/msg0018--no-inbody-headers
@@ -0,0 +1,8 @@
+From: Another Thor
+ <a.thor@example.com>
+Subject: This one contains
+ a tab
+ and a space
+
+a commit message
+
diff --git a/t/t5100/patch0018 b/t/t5100/patch0018
new file mode 100644
index 0000000..789df6d
--- /dev/null
+++ b/t/t5100/patch0018
@@ -0,0 +1,6 @@
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
diff --git a/t/t5100/patch0018--no-inbody-headers b/t/t5100/patch0018--no-inbody-headers
new file mode 100644
index 0000000..789df6d
--- /dev/null
+++ b/t/t5100/patch0018--no-inbody-headers
@@ -0,0 +1,6 @@
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 8b2ae06..6d4d0e4 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -699,3 +699,22 @@ index e69de29..d95f3ad 100644
+++ b/foo
@@ -0,0 +1 @@
+New content
+From nobody Mon Sep 17 00:00:00 2001
+From: A U Thor <a.u.thor@example.com>
+Subject: check multiline inbody headers
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
+From: Another Thor
+ <a.thor@example.com>
+Subject: This one contains
+ a tab
+ and a space
+
+a commit message
+
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
--
2.10.0.rc2.20.g5b18e70
^ permalink raw reply related
* Re: [PATCH v2 1/2] t5100-mailinfo: replace common path prefix with variable
From: Junio C Hamano @ 2016-09-19 21:16 UTC (permalink / raw)
To: Kevin Daudt; +Cc: git, Swift Geek, Jeff King
In-Reply-To: <20160919185440.18234-2-me@ikke.info>
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".
> test_expect_success 'split sample box' \
> - 'git mailsplit -o. "$TEST_DIRECTORY"/t5100/sample.mbox >last &&
> + 'git mailsplit -o. "$DATA"/sample.mbox >last &&
You are just following the pattern, and this instance is not too
bad, but lines like these
> - 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.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 2/2] mailinfo: unescape quoted-pair in header fields
From: Junio C Hamano @ 2016-09-19 21:24 UTC (permalink / raw)
To: Kevin Daudt; +Cc: git, Swift Geek, Jeff King
In-Reply-To: <20160919185440.18234-3-me@ikke.info>
Kevin Daudt <me@ikke.info> writes:
> +static void unquote_quoted_string(struct strbuf *line)
> +{
> + const char *in = strbuf_detach(line, NULL);
> + int c, take_next_literally = 0;
> + int found_error = 0;
> +
> + /*
> + * Stores the character that started the escape mode so that we know what
> + * character will stop it
> + */
> + char escape_context = 0;
> +
> + while ((c = *in++) != 0) {
> + if (take_next_literally) {
> + take_next_literally = 0;
> + } else {
> + switch (c) {
> + case '"':
> + if (!escape_context)
> + escape_context = '"';
> + else if (escape_context == '"')
> + escape_context = 0;
> + continue;
> + case '\\':
> + if (escape_context) {
> + take_next_literally = 1;
> + continue;
> + }
> + break;
> + case '(':
> + if (!escape_context)
> + escape_context = '(';
> + break;
> + case ')':
> + if (escape_context == '(')
> + escape_context = 0;
> + break;
> + }
> + }
> +
> + strbuf_addch(line, c);
> + }
> +}
The additional comment makes it very clear what is going on.
Is it an event unusual enough that is worth warning() about if we
have either take_next_literally or escape_context set to non-NUL
upon leaving the loop, I wonder?
Will queue. Thanks.
^ permalink raw reply
* Re: [PATCH v2 0/4] handle multiline in-body headers
From: Junio C Hamano @ 2016-09-19 21:39 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git, peff
In-Reply-To: <cover.1474319086.git.jonathantanmy@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
> This is an iteration of the patch set after the discussion in
> <cover.1474047135.git.jonathantanmy@google.com>.
>
> Changes:
> o largely rewritten to follow Junio's suggested design (refactor of
> check_header to separate out ">From" and "[PATCH]", and an
> is_inbody_header function performing an airtight check on whether a
> line is an in-body header)
> o simpler try_convert_to_utf8 API
> o one file of the expected output of t/t5100/*0015 is modified (instead
> of the input)
> o t/t5100/*0018--no-inbody-headers test files added
> o example in commit message improved following Peff's suggestion
Overall it looks much nicer, but I still do not understand why we
want to do try-convert-to-utf8. The _only_ caller of that helper
function is in 4/4 where it tries to convert the line to see if a
line is a scissors line.
It seems to me that the only thing doing so gives us is that you
could later enhance the definition of what a scissors-line looks
like by adding unicode characters [*1*], but I would strongly
suggest not doing that kind of enhancement [*2*]. With the current
definition of what a scissors-line looks like, it can be checked
before you do the UTF-8 conversion, I think, which would mean that
the helper is not strictly necessary.
So...
[Footnotes]
*1* E.g. ✂ encoded in non-UTF8 may have to be converted to UTF-8
first before being recognized as such.
*2* Encouraging people to use non-ASCII that older version of Git
did not take for structural things like "what is a scissors line"
merely for the looks is a bad trade-off; patch e-mails that use the
enhanced definition will break for those with older version of Git,
and the benefit of "prettier scissors" is not really worth it, I
would think.
^ permalink raw reply
* Re: [PATCH v2 2/2] mailinfo: unescape quoted-pair in header fields
From: Junio C Hamano @ 2016-09-19 22:04 UTC (permalink / raw)
To: Kevin Daudt; +Cc: git, Swift Geek, Jeff King
In-Reply-To: <xmqqvaxrd1ml.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Kevin Daudt <me@ikke.info> writes:
>
>> +static void unquote_quoted_string(struct strbuf *line)
>> +{
>> + const char *in = strbuf_detach(line, NULL);
>> + int c, take_next_literally = 0;
>> + int found_error = 0;
> ...
>> + }
>> +}
>
> The additional comment makes it very clear what is going on.
>
> Is it an event unusual enough that is worth warning() about if we
> have either take_next_literally or escape_context set to non-NUL
> upon leaving the loop, I wonder?
>
> Will queue. Thanks.
It turns out that found_error is not used anywhere and tripped the
-Werror=unused-variable check. I've removed that line while
queuing.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] ls-files: add pathspec matching for submodules
From: Junio C Hamano @ 2016-09-19 23:21 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <1474311151-117883-1-git-send-email-bmwill@google.com>
Brandon Williams <bmwill@google.com> writes:
> diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
> index a623ebf..09e4449 100644
> --- a/Documentation/git-ls-files.txt
> +++ b/Documentation/git-ls-files.txt
> @@ -19,7 +19,7 @@ SYNOPSIS
> - [--output-path-prefix=<path>]
> + [--submodule-prefix=<path>]
> ...
> ---output-path-prefix=<path>::
> +--submodule-prefix=<path>::
> ...
> -static const char *output_path_prefix;
> +static const char *submodule_prefix;
> ...
> - if (output_path_prefix && *output_path_prefix) {
> + if (submodule_prefix && *submodule_prefix) {
> strbuf_reset(&full_name);
> - strbuf_addstr(&full_name, output_path_prefix);
> + strbuf_addstr(&full_name, submodule_prefix);
> ...
> - argv_array_pushf(&cp.args, "--output-path-prefix=%s%s/",
> - output_path_prefix ? output_path_prefix : "",
> + argv_array_pushf(&cp.args, "--submodule-prefix=%s%s/",
> + submodule_prefix ? submodule_prefix : "",
> ce->name);
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.
> + /*
> + * 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).
> diff --git a/dir.c b/dir.c
> index 0ea235f..1afc3ff 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -63,6 +63,35 @@ int fspathncmp(const char *a, const char *b, size_t count)
> return ignore_case ? strncasecmp(a, b, count) : strncmp(a, b, count);
> }
>
> +/**
> + * Used to perform prefix matching against a pathspec_item for determining if we
> + * should decend into a submodule. This function can result in false positives
> + * since we are only trying to match the 'string' to a prefix of the 'pattern'
> + */
Perhaps s/can/is allowed to/. Implicit but equally important is
that it is not OK to produce false negative.
> +static int prefix_fnmatch(const struct pathspec_item *item,
> + const char *pattern, const char *string,
> + int prefix)
> +{
> + if (prefix > 0) {
> + if (ps_strncmp(item, pattern, string, prefix))
> + return WM_NOMATCH;
> + pattern += prefix;
> + string += prefix;
> + }
> +
> + 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.
Extending the scenario, if I also create a directory "sib/" in the
superproject next to "sub/" and add a "file" in it, the same
pathspec:
git ls-files [--recurse-submodules] ':(glob)??b/fi?e'
does find "sib/file" (with or without the recursion option).
Duy cc'ed because I am not quite sure why it is a good thing
that I need to add an exlicit ':(glob)' in these examples to
illustrate the breakage. This comes from v1.8.3.2-849-gbd30c2e
("pathspec: support :(glob) syntax", 2013-07-14) and I do not
think we want to change its behaviour. I just want to be
reminded why we did this. I am guessing that it was because of
an ancient design decision that we would use fnmatch without
FNM_PATHNAME by default, i.e. it would be too disruptive if we
made :(glob), i.e. honor directory boundaries, the default.
With :(glob) that follows FNM_PATHNAME behaviour, ":(glob)s*" would
be rejected as a match with "sub/file" or "sib/file", and that is
OK, but I think our ':(glob)??b/fi?e' example should find both of
these paths as matches to the pattern.
> +
> + return WM_NOMATCH;
> +}
> +
And of course, if it is not PATHSPEC_GLOB, returning NOMATCH does
not sound like erring on the side to prevent false negatives. For
example, what does
git ls-files --recurse-submodule '??b/fi?e'
do in the above scenario with this patch? Doesn't the if/else
cascade fall through and hit this return that says "Nah, 'sub'
cannot possibly match, do not bother descending into it"?
One thing I was originally confused about was that there are at
least three kinds we need to worry about.
- PATHSPEC_LITERAL, where we no-wildcard-len should cover
everything in the pattern string, e.g. "sub/file" may be the
pattern that would want to produce a match when trying to see if
we want to descend into "sub".
- PATHSPEC_GLOB, as discussed above.
- Not having either LITERAL or GLOB. 's*' would want to say that
it is worth descending into "sub". If there were another
submodule at "sob/dir", that would match the pattern 's*' as
well, because an asterisk can match 'ob/dir' part unlike in
PATHSPEC_GLOB case.
Thanks.
^ permalink raw reply
* What's cooking in git.git (Sep 2016, #05; Mon, 19)
From: Junio C Hamano @ 2016-09-19 23:30 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* ah/misc-message-fixes (2016-09-08) 5 commits
(merged to 'next' on 2016-09-12 at a113aea)
+ unpack-trees: do not capitalize "working"
+ git-merge-octopus: do not capitalize "octopus"
+ git-rebase--interactive: fix English grammar
+ cat-file: put spaces around pipes in usage string
+ am: put spaces around pipe in usage string
Message cleanup.
* bc/object-id (2016-09-07) 20 commits
(merged to 'next' on 2016-09-15 at 34c6459)
+ builtin/reset: convert to use struct object_id
+ builtin/commit-tree: convert to struct object_id
+ builtin/am: convert to struct object_id
+ refs: add an update_ref_oid function.
+ sha1_name: convert get_sha1_mb to struct object_id
+ builtin/update-index: convert file to struct object_id
+ notes: convert init_notes to use struct object_id
+ builtin/rm: convert to use struct object_id
+ builtin/blame: convert file to use struct object_id
+ Convert read_mmblob to take struct object_id.
+ notes-merge: convert struct notes_merge_pair to struct object_id
+ builtin/checkout: convert some static functions to struct object_id
+ streaming: make stream_blob_to_fd take struct object_id
+ builtin: convert textconv_object to use struct object_id
+ builtin/cat-file: convert some static functions to struct object_id
+ builtin/cat-file: convert struct expand_data to use struct object_id
+ builtin/log: convert some static functions to use struct object_id
+ builtin/blame: convert struct origin to use struct object_id
+ builtin/apply: convert static functions to struct object_id
+ cache: convert struct cache_entry to use struct object_id
The "unsigned char sha1[20]" to "struct object_id" conversion
continues. Notable changes in this round includes that ce->sha1,
i.e. the object name recorded in the cache_entry, turns into an
object_id.
It had merge conflicts with a few topics in flight (Christian's
"apply.c split", Dscho's "cat-file --filters" and Jeff Hostetler's
"status --porcelain-v2"). Extra sets of eyes double-checking for
mismerges are highly appreciated.
* cc/apply-am (2016-09-07) 41 commits
(merged to 'next' on 2016-09-12 at 854edde)
+ builtin/am: use apply API in run_apply()
+ apply: learn to use a different index file
+ apply: pass apply state to build_fake_ancestor()
+ apply: refactor `git apply` option parsing
+ apply: change error_routine when silent
+ usage: add get_error_routine() and get_warn_routine()
+ usage: add set_warn_routine()
+ apply: don't print on stdout in verbosity_silent mode
+ apply: make it possible to silently apply
+ apply: use error_errno() where possible
+ apply: make some parsing functions static again
+ apply: move libified code from builtin/apply.c to apply.{c,h}
+ apply: rename and move opt constants to apply.h
+ builtin/apply: rename option parsing functions
+ builtin/apply: make create_one_file() return -1 on error
+ builtin/apply: make try_create_file() return -1 on error
+ builtin/apply: make write_out_results() return -1 on error
+ builtin/apply: make write_out_one_result() return -1 on error
+ builtin/apply: make create_file() return -1 on error
+ builtin/apply: make add_index_file() return -1 on error
+ builtin/apply: make add_conflicted_stages_file() return -1 on error
+ builtin/apply: make remove_file() return -1 on error
+ builtin/apply: make build_fake_ancestor() return -1 on error
+ builtin/apply: change die_on_unsafe_path() to check_unsafe_path()
+ builtin/apply: make gitdiff_*() return -1 on error
+ builtin/apply: make gitdiff_*() return 1 at end of header
+ builtin/apply: make parse_traditional_patch() return -1 on error
+ builtin/apply: make apply_all_patches() return 128 or 1 on error
+ builtin/apply: move check_apply_state() to apply.c
+ builtin/apply: make check_apply_state() return -1 instead of die()ing
+ apply: make init_apply_state() return -1 instead of exit()ing
+ builtin/apply: move init_apply_state() to apply.c
+ builtin/apply: make parse_ignorewhitespace_option() return -1 instead of die()ing
+ builtin/apply: make parse_whitespace_option() return -1 instead of die()ing
+ builtin/apply: make parse_single_patch() return -1 on error
+ builtin/apply: make parse_chunk() return a negative integer on error
+ builtin/apply: make find_header() return -128 instead of die()ing
+ builtin/apply: read_patch_file() return -1 instead of die()ing
+ builtin/apply: make apply_patch() return -1 or -128 instead of die()ing
+ apply: move 'struct apply_state' to apply.h
+ apply: make some names more specific
"git am" has been taught to make an internal call to "git apply"'s
innards without spawning the latter as a separate process.
* jk/fix-remote-curl-url-wo-proto (2016-09-08) 1 commit
(merged to 'next' on 2016-09-12 at 7845867)
+ remote-curl: handle URLs without protocol
"git fetch http::/site/path" did not die correctly and segfaulted
instead.
* jk/pack-tag-of-tag (2016-09-07) 5 commits
(merged to 'next' on 2016-09-12 at 62c62c0)
+ pack-objects: walk tag chains for --include-tag
+ t5305: simplify packname handling
+ t5305: use "git -C"
+ t5305: drop "dry-run" of unpack-objects
+ t5305: move cleanup into test block
"git pack-objects --include-tag" was taught that when we know that
we are sending an object C, we want a tag B that directly points at
C but also a tag A that points at the tag B. We used to miss the
intermediate tag B in some cases.
* js/git-gui-commit-gpgsign (2016-09-11) 2 commits
(merged to 'next' on 2016-09-12 at 05350ab)
+ Merge branch 'js/commit-gpgsign' of ../git-gui into js/git-gui-commit-gpgsign
+ git-gui: respect commit.gpgsign again
"git commit-tree" stopped reading commit.gpgsign configuration
variable that was meant for Porcelain "git commit" in Git 2.9; we
forgot to update "git gui" to look at the configuration to match
this change.
* js/sequencer-wo-die (2016-09-09) 17 commits
(merged to 'next' on 2016-09-12 at d2154ea)
+ sequencer: ensure to release the lock when we could not read the index
+ sequencer: lib'ify checkout_fast_forward()
+ sequencer: lib'ify fast_forward_to()
+ sequencer: lib'ify save_opts()
+ sequencer: lib'ify save_todo()
+ sequencer: lib'ify save_head()
+ sequencer: lib'ify create_seq_dir()
+ sequencer: lib'ify read_populate_opts()
+ sequencer: lib'ify read_populate_todo()
+ sequencer: lib'ify read_and_refresh_cache()
+ sequencer: lib'ify prepare_revs()
+ sequencer: lib'ify walk_revs_populate_todo()
+ sequencer: lib'ify do_pick_commit()
+ sequencer: lib'ify do_recursive_merge()
+ sequencer: lib'ify write_message()
+ sequencer: do not die() in do_pick_commit()
+ sequencer: lib'ify sequencer_pick_revisions()
Lifts calls to exit(2) and die() higher in the callchain in
sequencer.c files so that more helper functions in it can be used
by callers that want to handle error conditions themselves.
* mh/ref-store (2016-09-09) 38 commits
(merged to 'next' on 2016-09-12 at 1b0bd3c)
+ refs: implement iteration over only per-worktree refs
+ refs: make lock generic
+ refs: add method to rename refs
+ refs: add methods to init refs db
+ refs: make delete_refs() virtual
+ refs: add method for initial ref transaction commit
+ refs: add methods for reflog
+ refs: add method iterator_begin
+ files_ref_iterator_begin(): take a ref_store argument
+ split_symref_update(): add a files_ref_store argument
+ lock_ref_sha1_basic(): add a files_ref_store argument
+ lock_ref_for_update(): add a files_ref_store argument
+ commit_ref_update(): add a files_ref_store argument
+ lock_raw_ref(): add a files_ref_store argument
+ repack_without_refs(): add a files_ref_store argument
+ refs: make peel_ref() virtual
+ refs: make create_symref() virtual
+ refs: make pack_refs() virtual
+ refs: make verify_refname_available() virtual
+ refs: make read_raw_ref() virtual
+ resolve_gitlink_ref(): rename path parameter to submodule
+ resolve_gitlink_ref(): avoid memory allocation in many cases
+ resolve_gitlink_ref(): implement using resolve_ref_recursively()
+ resolve_ref_recursively(): new function
+ read_raw_ref(): take a (struct ref_store *) argument
+ resolve_gitlink_packed_ref(): remove function
+ resolve_packed_ref(): rename function from resolve_missing_loose_ref()
+ refs: reorder definitions
+ refs: add a transaction_commit() method
+ {lock,commit,rollback}_packed_refs(): add files_ref_store arguments
+ resolve_missing_loose_ref(): add a files_ref_store argument
+ get_packed_ref(): add a files_ref_store argument
+ add_packed_ref(): add a files_ref_store argument
+ refs: create a base class "ref_store" for files_ref_store
+ refs: add a backend method structure
+ refs: rename struct ref_cache to files_ref_store
+ rename_ref_available(): add docstring
+ resolve_gitlink_ref(): eliminate temporary variable
The ref-store abstraction was introduced to the refs API so that we
can plug in different backends to store references.
* sb/diff-cleanup (2016-09-08) 3 commits
(merged to 'next' on 2016-09-12 at 5d16b28)
+ diff: remove dead code
+ diff: omit found pointer from emit_callback
+ diff.c: use diff_options directly
Code cleanup.
* sy/git-gui-i18n-ja (2016-09-07) 7 commits
(merged to 'next' on 2016-09-12 at 4a701c2)
+ Merge branch 'sy/i18n' of git-gui
+ git-gui: update Japanese information
+ git-gui: update Japanese translation
+ git-gui: add Japanese language code
+ git-gui: apply po template to Japanese translation
+ git-gui: consistently use the same word for "blame" in Japanese
+ git-gui: consistently use the same word for "remote" in Japanese
Update Japanese translation for "git-gui".
--------------------------------------------------
[New Topics]
* rs/xdiff-merge-overlapping-hunks-for-W-context (2016-09-14) 1 commit
(merged to 'next' on 2016-09-15 at eaa85ab)
+ xdiff: fix merging of hunks with -W context and -u context
"git diff -W" output needs to extend the context backward to
include the header line of the current function and also forward to
include the body of the entire current function up to the header
line of the next one. This process may have to merge to adjacent
hunks, but the code forgot to do so in some cases.
Will merge to 'master'.
* mm/config-color-ui-default-to-auto (2016-09-16) 1 commit
- Documentation/config: default for color.* is color.ui
Documentation for individual configuration variables to control use
of color (like `color.grep`) said that their default value was
'false', instead of saying their default is taken from `color.ui`.
When we updated the default value for color.ui from 'false' to
'auto' quite a while ago, all of them broke. This has been
corrected.
Will merge to 'next'.
* rs/c-auto-resets-attributes (2016-09-19) 1 commit
- pretty: let %C(auto) reset all attributes
The pretty-format specifier used by the "log" family of commands
have "%C(auto)" to turn coloring of the output is taught to also
issue a color-reset sequence to the output.
Will merge to 'next'.
* rs/cocci (2016-09-15) 3 commits
- use strbuf_addstr() for adding constant strings to a strbuf, part 2
- add coccicheck make target
- contrib/coccinelle: fix semantic patch for oid_to_hex_r()
Code cleanup.
Will merge to 'next'.
* va/i18n-more (2016-09-19) 6 commits
- i18n: stash: mark messages for translation
- i18n: notes-merge: mark die messages for translation
- i18n: ident: mark hint for translation
- i18n: diff: mark die errors for translation
- i18n: connect: mark die messages for translation
- i18n: commit: mark message for translation
(this branch uses va/i18n.)
Even more i18n.
Will merge to 'next'.
* jt/mailinfo-fold-in-body-headers (2016-09-19) 2 commits
- mailinfo: make is_scissors_line take plain char *
- mailinfo: separate in-body header processing
* kd/mailinfo-quoted-string (2016-09-19) 2 commits
- mailinfo: unescape quoted-pair in header fields
- t5100-mailinfo: replace common path prefix with variable
--------------------------------------------------
[Stalled]
* jc/bundle (2016-03-03) 6 commits
- index-pack: --clone-bundle option
- Merge branch 'jc/index-pack' into jc/bundle
- bundle v3: the beginning
- bundle: keep a copy of bundle file name in the in-core bundle header
- bundle: plug resource leak
- bundle doc: 'verify' is not about verifying the bundle
The beginning of "split bundle", which could be one of the
ingredients to allow "git clone" traffic off of the core server
network to CDN.
While I think it would make it easier for people to experiment and
build on if the topic is merged to 'next', I am at the same time a
bit reluctant to merge an unproven new topic that introduces a new
file format, which we may end up having to support til the end of
time. It is likely that to support a "prime clone from CDN", it
would need a lot more than just "these are the heads and the pack
data is over there", so this may not be sufficient.
Will discard.
* jc/blame-reverse (2016-06-14) 2 commits
- blame: dwim "blame --reverse OLD" as "blame --reverse OLD.."
- blame: improve diagnosis for "--reverse NEW"
It is a common mistake to say "git blame --reverse OLD path",
expecting that the command line is dwimmed as if asking how lines
in path in an old revision OLD have survived up to the current
commit.
Has been waiting for positive responses without seeing any.
Will discard.
* jc/attr (2016-05-25) 18 commits
- attr: support quoting pathname patterns in C style
- attr: expose validity check for attribute names
- attr: add counted string version of git_attr()
- attr: add counted string version of git_check_attr()
- attr: retire git_check_attrs() API
- attr: convert git_check_attrs() callers to use the new API
- attr: convert git_all_attrs() to use "struct git_attr_check"
- attr: (re)introduce git_check_attr() and struct git_attr_check
- attr: rename function and struct related to checking attributes
- attr.c: plug small leak in parse_attr_line()
- attr.c: tighten constness around "git_attr" structure
- attr.c: simplify macroexpand_one()
- attr.c: mark where #if DEBUG ends more clearly
- attr.c: complete a sentence in a comment
- attr.c: explain the lack of attr-name syntax check in parse_attr()
- attr.c: update a stale comment on "struct match_attr"
- attr.c: use strchrnul() to scan for one line
- commit.c: use strchrnul() to scan for one line
(this branch is used by jc/attr-more, sb/pathspec-label and sb/submodule-default-paths.)
The attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
I wanted to polish this topic further to make the attribute
subsystem thread-ready, but because other topics depend on this
topic and they do not (yet) need it to be thread-ready.
As the authors of topics that depend on this seem not in a hurry,
let's discard this and dependent topics and restart them some other
day.
Will discard.
* jc/attr-more (2016-06-09) 8 commits
- attr.c: outline the future plans by heavily commenting
- attr.c: always pass check[] to collect_some_attrs()
- attr.c: introduce empty_attr_check_elems()
- attr.c: correct ugly hack for git_all_attrs()
- attr.c: rename a local variable check
- fixup! d5ad6c13
- attr.c: pass struct git_attr_check down the callchain
- attr.c: add push_stack() helper
(this branch uses jc/attr; is tangled with sb/pathspec-label and sb/submodule-default-paths.)
The beginning of long and tortuous journey to clean-up attribute
subsystem implementation.
Needs to be redone.
Will discard.
* sb/submodule-default-paths (2016-06-20) 5 commits
- completion: clone can recurse into submodules
- clone: add --init-submodule=<pathspec> switch
- submodule update: add `--init-default-path` switch
- Merge branch 'sb/pathspec-label' into sb/submodule-default-paths
- Merge branch 'jc/attr' into sb/submodule-default-paths
(this branch uses jc/attr and sb/pathspec-label; is tangled with jc/attr-more.)
Allow specifying the set of submodules the user is interested in on
the command line of "git clone" that clones the superproject.
Will discard.
* sb/pathspec-label (2016-06-03) 6 commits
- pathspec: disable preload-index when attribute pathspec magic is in use
- pathspec: allow escaped query values
- pathspec: allow querying for attributes
- pathspec: move prefix check out of the inner loop
- pathspec: move long magic parsing out of prefix_pathspec
- Documentation: fix a typo
(this branch is used by sb/submodule-default-paths; uses jc/attr; is tangled with jc/attr-more.)
The pathspec mechanism learned ":(attr:X)$pattern" pathspec magic
to limit paths that match $pattern further by attribute settings.
The preload-index mechanism is disabled when the new pathspec magic
is in use (at least for now), because the attribute subsystem is
not thread-ready.
Will discard.
* mh/connect (2016-06-06) 10 commits
- connect: [host:port] is legacy for ssh
- connect: move ssh command line preparation to a separate function
- connect: actively reject git:// urls with a user part
- connect: change the --diag-url output to separate user and host
- connect: make parse_connect_url() return the user part of the url as a separate value
- connect: group CONNECT_DIAG_URL handling code
- connect: make parse_connect_url() return separated host and port
- connect: re-derive a host:port string from the separate host and port variables
- connect: call get_host_and_port() earlier
- connect: document why we sometimes call get_port after get_host_and_port
Rewrite Git-URL parsing routine (hopefully) without changing any
behaviour.
It has been two months without any support. We may want to discard
this.
* sb/bisect (2016-04-15) 22 commits
. SQUASH???
. bisect: get back halfway shortcut
. bisect: compute best bisection in compute_relevant_weights()
. bisect: use a bottom-up traversal to find relevant weights
. bisect: prepare for different algorithms based on find_all
. bisect: rename count_distance() to compute_weight()
. bisect: make total number of commits global
. bisect: introduce distance_direction()
. bisect: extract get_distance() function from code duplication
. bisect: use commit instead of commit list as arguments when appropriate
. bisect: replace clear_distance() by unique markers
. bisect: use struct node_data array instead of int array
. bisect: get rid of recursion in count_distance()
. bisect: make algorithm behavior independent of DEBUG_BISECT
. bisect: make bisect compile if DEBUG_BISECT is set
. bisect: plug the biggest memory leak
. bisect: add test for the bisect algorithm
. t6030: generalize test to not rely on current implementation
. t: use test_cmp_rev() where appropriate
. t/test-lib-functions.sh: generalize test_cmp_rev
. bisect: allow 'bisect run' if no good commit is known
. bisect: write about `bisect next` in documentation
The internal algorithm used in "git bisect" to find the next commit
to check has been optimized greatly.
Was expecting a reroll, but now pb/bisect topic starts removinging
more and more parts from git-bisect.sh, this needs to see a fresh
reroll.
Will discard.
cf. <1460294354-7031-1-git-send-email-s-beyer@gmx.net>
* sg/completion-updates (2016-02-28) 21 commits
. completion: cache the path to the repository
. completion: extract repository discovery from __gitdir()
. completion: don't guard git executions with __gitdir()
. completion: consolidate silencing errors from git commands
. completion: don't use __gitdir() for git commands
. completion: respect 'git -C <path>'
. completion: fix completion after 'git -C <path>'
. completion: don't offer commands when 'git --opt' needs an argument
. rev-parse: add '--absolute-git-dir' option
. completion: list short refs from a remote given as a URL
. completion: don't list 'HEAD' when trying refs completion outside of a repo
. completion: list refs from remote when remote's name matches a directory
. completion: respect 'git --git-dir=<path>' when listing remote refs
. completion: fix most spots not respecting 'git --git-dir=<path>'
. completion: ensure that the repository path given on the command line exists
. completion tests: add tests for the __git_refs() helper function
. completion tests: check __gitdir()'s output in the error cases
. completion tests: consolidate getting path of current working directory
. completion tests: make the $cur variable local to the test helper functions
. completion tests: don't add test cruft to the test repository
. completion: improve __git_refs()'s in-code documentation
Has been waiting for a reroll for too long.
cf. <1456754714-25237-1-git-send-email-szeder@ira.uka.de>
Will discard.
* ec/annotate-deleted (2015-11-20) 1 commit
- annotate: skip checking working tree if a revision is provided
Usability fix for annotate-specific "<file> <rev>" syntax with deleted
files.
Has been waiting for a review for too long without seeing anything.
Will discard.
* dk/gc-more-wo-pack (2016-01-13) 4 commits
- gc: clean garbage .bitmap files from pack dir
- t5304: ensure non-garbage files are not deleted
- t5304: test .bitmap garbage files
- prepare_packed_git(): find more garbage
Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
.bitmap and .keep files.
Has been waiting for a reroll for too long.
cf. <xmqq60ypbeng.fsf@gitster.mtv.corp.google.com>
Will discard.
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
"git diff -B -M" produced incorrect patch when the postimage of a
completely rewritten file is similar to the preimage of a removed
file; such a resulting file must not be expressed as a rename from
other place.
The fix in this patch is broken, unfortunately.
Will discard.
--------------------------------------------------
[Cooking]
* et/add-chmod-x (2016-09-12) 1 commit
(merged to 'next' on 2016-09-15 at c81abae)
+ add: document the chmod option
(this branch is used by tg/add-chmod+x-fix.)
"git add --chmod=+x" added recently lacked documentation, which has
been corrected.
Will merge to 'master'.
* js/libify-require-clean-work-tree (2016-09-12) 5 commits
- wt-status: teach has_{unstaged,uncommitted}_changes() about submodules
- Export also the has_un{staged,committed}_changed() functions
- Make the require_clean_work_tree() function truly reusable
- pull: make code more similar to the shell script again
- pull: drop confusing prefix parameter of die_on_unclean_work_tree()
The require_clean_work_tree() helper was recreated in C when "git
pull" was rewritten from shell; the helper is now made available to
other callers in preparation for upcoming "rebase -i" work.
Waiting for comments.
Modulo a few minor nits, this looked almost ready.
cf. <xmqqtwdl2bhm.fsf@gitster.mtv.corp.google.com>
cf. <xmqqpoo92bdr.fsf@gitster.mtv.corp.google.com>
* ks/perf-build-with-autoconf (2016-09-15) 1 commit
(merged to 'next' on 2016-09-15 at 261878d)
+ t/perf/run: copy config.mak.autogen & friends to build area
Performance tests done via "t/perf" did not use the same set of
build configuration if the user relied on autoconf generated
configuration.
Will merge to 'master'.
* tg/add-chmod+x-fix (2016-09-15) 4 commits
(merged to 'next' on 2016-09-15 at a97bdfd)
+ add: modify already added files when --chmod is given
+ read-cache: introduce chmod_index_entry
+ update-index: add test for chmod flags
+ Merge branch 'ib/t3700-add-chmod-x-updates' into tg/add-chmod+x-fix
(this branch uses et/add-chmod-x.)
"git add --chmod=+x <pathspec>" added recently only toggled the
executable bit for paths that are either new or modified. This has
been corrected to flip the executable bit for all paths that match
the given pathspec.
Will merge to 'master'.
* bw/ls-files-recurse-submodules (2016-09-13) 3 commits
- SQUASH??? Undecided
- SQUASH???
- ls-files: adding support for submodules
"git ls-files" learned "--recurse-submodules" option that can be
used to get a listing of tracked files across submodules (i.e. this
only works with "--cached" option, not for listing untracked or
ignored files). This would be a useful tool to sit on the upstream
side of a pipe that is read with xargs to work on all working tree
files from the top-level superproject.
Waiting for the discussion to conclude.
* bw/pathspec-remove-unused-extern-decl (2016-09-13) 1 commit
(merged to 'next' on 2016-09-15 at c5b281b)
+ pathspec: remove unnecessary function prototypes
Code cleanup.
Will merge to 'master'.
* ew/http-do-not-forget-to-call-curl-multi-remove-handle (2016-09-13) 3 commits
(merged to 'next' on 2016-09-15 at 696acb7)
+ http: always remove curl easy from curlm session on release
+ http: consolidate #ifdefs for curl_multi_remove_handle
+ http: warn on curl_multi_add_handle failures
The http transport (with curl-multi option, which is the default
these days) failed to remove curl-easy handle from a curlm session,
which led to unnecessary API failures.
Will merge to 'master'.
* jk/delta-base-cache (2016-09-12) 1 commit
(merged to 'next' on 2016-09-15 at 1e35f8d)
+ add_delta_base_cache: use list_for_each_safe
Recently we updated the code to manage the in-core cache that holds
objects that have recently been used to reconstitute other objects
that are stored as deltas against them, but the update used an
incorrect API function to manage the list of these objects. This
has been fixed.
Will merge to 'master'.
This is a last-minute fix to a topic that graduated to 'master'
post 2.10 release.
* jk/setup-sequence-update (2016-09-13) 16 commits
(merged to 'next' on 2016-09-15 at 4df8399)
+ t1007: factor out repeated setup
+ init: reset cached config when entering new repo
+ init: expand comments explaining config trickery
+ config: only read .git/config from configured repos
+ test-config: setup git directory
+ t1302: use "git -C"
+ pager: handle early config
+ pager: use callbacks instead of configset
+ pager: make pager_program a file-local static
+ pager: stop loading git_default_config()
+ pager: remove obsolete comment
+ diff: always try to set up the repository
+ diff: handle --no-index prefixes consistently
+ diff: skip implicit no-index check when given --no-index
+ patch-id: use RUN_SETUP_GENTLY
+ hash-object: always try to set up the git repository
There were numerous corner cases in which the configuration files
are read and used or not read at all depending on the directory a
Git command was run, leading to inconsistent behaviour. The code
to set-up repository access at the beginning of a Git process has
been updated to fix them.
Will merge to 'master'.
* ls/filter-process (2016-09-13) 10 commits
- convert: add filter.<driver>.process option
- convert: make apply_filter() adhere to standard Git error handling
- convert: modernize tests
- convert: quote filter names in error messages
- pkt-line: add functions to read/write flush terminated packet streams
- pkt-line: add packet_write_gently()
- pkt-line: add packet_flush_gently()
- pkt-line: add packet_write_fmt_gently()
- pkt-line: extract set_packet_header()
- pkt-line: rename packet_write() to packet_write_fmt()
The smudge/clean filter API expect an external process is spawned
to filter the contents for each path that has a filter defined. A
new type of "process" filter API has been added to allow the first
request to run the filter for a path to spawn a single process, and
all filtering need is served by this single process for multiple
paths, reducing the process creation overhead.
Waiting for the discussion to conclude.
cf. <20160910062919.GB11001@tb-raspi> etc.
* rs/checkout-some-states-are-const (2016-09-13) 1 commit
(merged to 'next' on 2016-09-15 at 19f219b)
+ checkout: constify parameters of checkout_stage() and checkout_merged()
Code cleanup.
Will merge to 'master'.
* rs/pack-sort-with-llist-mergesort (2016-09-13) 1 commit
(merged to 'next' on 2016-09-15 at 45159f5)
+ sha1_file: use llist_mergesort() for sorting packs
Code cleanup.
Will merge to 'master'.
* rs/strbuf-remove-fix (2016-09-13) 1 commit
(merged to 'next' on 2016-09-15 at 5f64556)
+ strbuf: use valid pointer in strbuf_remove()
Code cleanup.
Will merge to 'master'.
* rs/unpack-trees-reduce-file-scope-global (2016-09-13) 1 commit
(merged to 'next' on 2016-09-15 at cd16435)
+ unpack-trees: pass checkout state explicitly to check_updates()
Code cleanup.
Will merge to 'master'.
* mr/vcs-svn-printf-ulong (2016-09-14) 1 commit
(merged to 'next' on 2016-09-15 at cc8ef53)
+ vcs-svn/fast_export: fix timestamp fmt specifiers
Code cleanup.
Will merge to 'master'.
* hv/submodule-not-yet-pushed-fix (2016-09-15) 5 commits
. SQUASH??? -Wdecl-after-stmt
. use actual start hashes for submodule push check instead of local refs
. batch check whether submodule needs pushing into one call
- serialize collection of refs that contain submodule changes
- serialize collection of changed submodules
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. This has been optimized.
The last two in the original series seem to break a few tests when
queued to 'pu'.
* jk/patch-ids-no-merges (2016-09-12) 2 commits
(merged to 'next' on 2016-09-15 at 14bb3a0)
+ patch-ids: refuse to compute patch-id for merge commit
+ patch-ids: turn off rename detection
"git log --cherry-pick" used to include merge commits as candidates
to be matched up with other commits, resulting a lot of wasted time.
The patch-id generation logic has been updated to ignore merges to
avoid the wastage.
Will merge to 'master'.
* jt/accept-capability-advertisement-when-fetching-from-void (2016-09-09) 3 commits
(merged to 'next' on 2016-09-15 at 1cd9f9a)
+ connect: advertized capability is not a ref
+ connect: tighten check for unexpected early hang up
+ tests: move test_lazy_prereq JGIT to test-lib.sh
JGit can show a fake ref "capabilities^{}" to "git fetch" when it
does not advertise any refs, but "git fetch" was not prepared to
see such an advertisement. When the other side disconnects without
giving any ref advertisement, we used to say "there may not be a
repository at that URL", but we may have seen other advertisement
like "shallow" and ".have" in which case we definitely know that a
repository is there. The code to detect this case has also been
updated.
Will merge to 'master'.
* rt/rebase-i-broken-insn-advise (2016-09-07) 1 commit
- rebase -i: improve advice on bad instruction lines
When "git rebase -i" is given a broken instruction, it told the
user to fix it with "--edit-todo", but didn't say what the step
after that was (i.e. "--continue").
Will hold.
Dscho's "rebase -i" hopefully will become available in 'pu', by
which time an equivalent of this fix would be ported to C. This is
queued merely as a reminder.
* jt/format-patch-base-info-above-sig (2016-09-15) 1 commit
(merged to 'next' on 2016-09-15 at 3da5c68)
+ format-patch: show base info before email signature
"git format-patch --base=..." feature that was recently added
showed the base commit information after "-- " e-mail signature
line, which turned out to be inconvenient. The base information
has been moved above the signature line.
Will merge to 'master'.
* nd/checkout-disambiguation (2016-09-09) 4 commits
- fixup! checkout.txt: document a common case that ignores ambiguation rules
- checkout: fix ambiguity check in subdir
- checkout.txt: document a common case that ignores ambiguation rules
- checkout: add some spaces between code and comment
"git checkout <word>" does not follow the usual disambiguation
rules when the <word> can be both a rev and a path, to allow
checking out a branch 'foo' in a project that happens to have a
file 'foo' in the working tree without having to disambiguate.
This was poorly documented and the check was incorrect when the
command was run from a subdirectory.
Waiting for an Ack for fixup!
* sg/fix-versioncmp-with-common-suffix (2016-09-08) 5 commits
- versioncmp: cope with common leading parts in versionsort.prereleaseSuffix
- versioncmp: pass full tagnames to swap_prereleases()
- t7004-tag: add version sort tests to show prerelease reordering issues
- t7004-tag: use test_config helper
- t7004-tag: delete unnecessary tags with test_when_finished
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).
Waiting for a reroll.
cf. <20160908223727.Horde.jVOOJ278ssZ3qkyjkmyqZD-@webmail.informatik.kit.edu>
* va/i18n (2016-09-15) 11 commits
(merged to 'next' on 2016-09-15 at 2b3d368)
+ i18n: update-index: mark warnings for translation
+ i18n: show-branch: mark plural strings for translation
+ i18n: show-branch: mark error messages for translation
+ i18n: receive-pack: mark messages for translation
+ notes: spell first word of error messages in lowercase
+ i18n: notes: mark error messages for translation
+ i18n: merge-recursive: mark verbose message for translation
+ i18n: merge-recursive: mark error messages for translation
+ i18n: config: mark error message for translation
+ i18n: branch: mark option description for translation
+ i18n: blame: mark error messages for translation
(this branch is used by va/i18n-more.)
More i18n.
Will merge to 'master'.
* cp/completion-negative-refs (2016-08-24) 1 commit
- completion: support excluding refs
The command-line completion script (in contrib/) learned to
complete "git cmd ^mas<HT>" to complete the negative end of
reference to "git cmd ^master".
Needs review.
* js/cat-file-filters (2016-09-11) 4 commits
(merged to 'next' on 2016-09-15 at a231380)
+ cat-file: support --textconv/--filters in batch mode
+ cat-file --textconv/--filters: allow specifying the path separately
+ cat-file: introduce the --filters option
+ cat-file: fix a grammo in the man page
Even though "git hash-objects", which is a tool to take an
on-filesystem data stream and put it into the Git object store,
allowed to perform the "outside-world-to-Git" conversions (e.g.
end-of-line conversions and application of the clean-filter), and
it had the feature on by default from very early days, its reverse
operation "git cat-file", which takes an object from the Git object
store and externalize for the consumption by the outside world,
lacked an equivalent mechanism to run the "Git-to-outside-world"
conversion. The command learned the "--filters" option to do so.
Will merge to 'master'.
* sb/push-make-submodule-check-the-default (2016-08-24) 1 commit
- push: change submodule default to check
Turn the default of "push.recurseSubmodules" to "check".
Alas, this reveals that the "check" mode is too inefficient to use
in real projects, even in ones as small as git itself.
cf. <xmqqh9aaot49.fsf@gitster.mtv.corp.google.com>
* ak/curl-imap-send-explicit-scheme (2016-08-17) 1 commit
- imap-send: Tell cURL to use imap:// or imaps://
When we started cURL to talk to imap server when a new enough
version of cURL library is available, we forgot to explicitly add
imap(s):// before the destination. To some folks, that didn't work
and the library tried to make HTTP(s) requests instead.
Needs review and testing.
* jk/reduce-gc-aggressive-depth (2016-08-11) 1 commit
(merged to 'next' on 2016-08-11 at 6810c6f)
+ gc: default aggressive depth to 50
"git gc --aggressive" used to limit the delta-chain length to 250,
which is way too deep for gaining additional space savings and is
detrimental for runtime performance. The limit has been reduced to
50.
Will hold to see if people scream.
* ks/pack-objects-bitmap (2016-09-12) 2 commits
(merged to 'next' on 2016-09-15 at e0600bd)
+ pack-objects: use reachability bitmap index when generating non-stdout pack
+ pack-objects: respect --local/--honor-pack-keep/--incremental when bitmap is in use
Some codepaths in "git pack-objects" were not ready to use an
existing pack bitmap; now they are and as the result they have
become faster.
Will merge to 'master'.
* mh/diff-indent-heuristic (2016-09-19) 8 commits
- blame: honor the diff heuristic options and config
- parse-options: add parse_opt_unknown_cb()
- diff: improve positioning of add/delete blocks in diffs
- xdl_change_compact(): introduce the concept of a change group
- recs_match(): take two xrecord_t pointers as arguments
- is_blank_line(): take a single xrecord_t as argument
- xdl_change_compact(): only use heuristic if group can't be matched
- xdl_change_compact(): fix compaction heuristic to adjust ixo
Output from "git diff" can be made easier to read by selecting
which lines are common and which lines are added/deleted
intelligently when the lines before and after the changed section
are the same. A command line option is added to help with the
experiment to find a good heuristics.
Will merge to 'next'.
* jk/pack-objects-optim-mru (2016-08-11) 4 commits
(merged to 'next' on 2016-08-11 at c0a7dae)
+ pack-objects: use mru list when iterating over packs
+ pack-objects: break delta cycles before delta-search phase
+ sha1_file: make packed_object_info public
+ provide an initializer for "struct object_info"
"git pack-objects" in a repository with many packfiles used to
spend a lot of time looking for/at objects in them; the accesses to
the packfiles are now optimized by checking the most-recently-used
packfile first.
Will hold to see if people scream.
* jk/rebase-i-drop-ident-check (2016-07-29) 1 commit
(merged to 'next' on 2016-08-14 at 6891bcd)
+ rebase-interactive: drop early check for valid ident
Even when "git pull --rebase=preserve" (and the underlying "git
rebase --preserve") can complete without creating any new commit
(i.e. fast-forwards), it still insisted on having a usable ident
information (read: user.email is set correctly), which was less
than nice. As the underlying commands used inside "git rebase"
would fail with a more meaningful error message and advice text
when the bogus ident matters, this extra check was removed.
Will hold to see if people scream.
cf. <20160729224944.GA23242@sigill.intra.peff.net>
* dp/autoconf-curl-ssl (2016-06-28) 1 commit
- ./configure.ac: detect SSL in libcurl using curl-config
The ./configure script generated from configure.ac was taught how
to detect support of SSL by libcurl better.
Needs review.
* jc/pull-rebase-ff (2016-07-28) 1 commit
- pull: fast-forward "pull --rebase=true"
"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.
Needs a real log message and a few tests.
* ex/deprecate-empty-pathspec-as-match-all (2016-06-22) 1 commit
(merged to 'next' on 2016-07-13 at d9ca7fb)
+ pathspec: warn on empty strings as pathspec
An empty string used as a pathspec element has always meant
'everything matches', but it is too easy to write a script that
finds a path to remove in $path and run 'git rm "$paht"', which
ends up removing everything. Start warning about this use of an
empty string used for 'everything matches' and ask 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.
Will hold to see if people scream.
* nd/shallow-deepen (2016-06-13) 27 commits
- fetch, upload-pack: --deepen=N extends shallow boundary by N commits
- upload-pack: add get_reachable_list()
- upload-pack: split check_unreachable() in two, prep for get_reachable_list()
- t5500, t5539: tests for shallow depth excluding a ref
- clone: define shallow clone boundary with --shallow-exclude
- fetch: define shallow boundary with --shallow-exclude
- upload-pack: support define shallow boundary by excluding revisions
- refs: add expand_ref()
- t5500, t5539: tests for shallow depth since a specific date
- clone: define shallow clone boundary based on time with --shallow-since
- fetch: define shallow boundary with --shallow-since
- upload-pack: add deepen-since to cut shallow repos based on time
- shallow.c: implement a generic shallow boundary finder based on rev-list
- fetch-pack: use a separate flag for fetch in deepening mode
- fetch-pack.c: mark strings for translating
- fetch-pack: use a common function for verbose printing
- fetch-pack: use skip_prefix() instead of starts_with()
- upload-pack: move rev-list code out of check_non_tip()
- upload-pack: make check_non_tip() clean things up on error
- upload-pack: tighten number parsing at "deepen" lines
- upload-pack: use skip_prefix() instead of starts_with()
- upload-pack: move "unshallow" sending code out of deepen()
- upload-pack: remove unused variable "backup"
- upload-pack: move "shallow" sending code out of deepen()
- upload-pack: move shallow deepen code out of receive_needs()
- transport-helper.c: refactor set_helper_option()
- remote-curl.c: convert fetch_git() to use argv_array
The existing "git fetch --depth=<n>" option was hard to use
correctly when making the history of an existing shallow clone
deeper. A new option, "--deepen=<n>", has been added to make this
easier to use. "git clone" also learned "--shallow-since=<date>"
and "--shallow-exclude=<tag>" options to make it easier to specify
"I am interested only in the recent N months worth of history" and
"Give me only the history since that version".
Needs review.
Rerolled. What this topic attempts to achieve is worthwhile, I
would think.
* pb/bisect (2016-08-23) 27 commits
. bisect--helper: remove the dequote in bisect_start()
. bisect--helper: retire `--bisect-auto-next` subcommand
. bisect--helper: retire `--bisect-autostart` subcommand
. bisect--helper: retire `--check-and-set-terms` subcommand
. bisect--helper: retire `--bisect-write` subcommand
. bisect--helper: `bisect_replay` shell function in C
. bisect--helper: `bisect_log` shell function in C
. bisect--helper: retire `--write-terms` subcommand
. bisect--helper: retire `--check-expected-revs` subcommand
. bisect--helper: `bisect_state` & `bisect_head` shell function in C
. bisect--helper: `bisect_autostart` shell function in C
. bisect--helper: retire `--next-all` subcommand
. bisect--helper: retire `--bisect-clean-state` subcommand
. bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
. bisect--helper: `bisect_start` shell function partially in C
. bisect--helper: `get_terms` & `bisect_terms` shell function in C
. bisect--helper: `bisect_next_check` & bisect_voc shell function in C
. bisect--helper: `check_and_set_terms` shell function in C
. bisect--helper: `bisect_write` shell function in C
. bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
. bisect--helper: `bisect_reset` shell function in C
. wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
. t6030: explicitly test for bisection cleanup
. bisect--helper: `bisect_clean_state` shell function in C
. bisect--helper: `write_terms` shell function in C
. bisect: rewrite `check_term_format` shell function in C
. bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
GSoC "bisect" topic.
I'd prefer to see early part solidified so that reviews can focus
on the later part that is still in flux. We are almost there but
not quite yet.
* kn/ref-filter-branch-list (2016-05-17) 17 commits
- branch: implement '--format' option
- branch: use ref-filter printing APIs
- branch, tag: use porcelain output
- ref-filter: allow porcelain to translate messages in the output
- ref-filter: add `:dir` and `:base` options for ref printing atoms
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce symref_atom_parser() and refname_atom_parser()
- ref-filter: introduce refname_atom_parser_internal()
- ref-filter: make "%(symref)" atom work with the ':short' modifier
- ref-filter: add support for %(upstream:track,nobracket)
- ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
- ref-filter: introduce format_ref_array_item()
- ref-filter: move get_head_description() from branch.c
- ref-filter: modify "%(objectname:short)" to take length
- ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
- ref-filter: include reference to 'used_atom' within 'atom_value'
- ref-filter: implement %(if), %(then), and %(else) atoms
The code to list branches in "git branch" has been consolidated
with the more generic ref-filter API.
Rerolled.
Needs review.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
- merge: drop 'git merge <message> HEAD <commit>' syntax
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
It has been reported that git-gui still uses the deprecated syntax,
which needs to be fixed before this final step can proceed.
cf. <5671DB28.8020901@kdbg.org>
--------------------------------------------------
[Discarded]
* jn/fix-connect-unexpected-hangup-diag (2016-09-08) 1 commit
. connect: tighten check for unexpected early hang up
Now part of jt/accept-capability-advertisement-when-fetching-from-void
topic.
^ permalink raw reply
* Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]
From: Jeff King @ 2016-09-19 23:34 UTC (permalink / raw)
To: Josh Triplett; +Cc: Junio C Hamano, Andrew Donnellan, git
In-Reply-To: <20160919204408.GA28962@cloud>
On Mon, Sep 19, 2016 at 01:44:08PM -0700, Josh Triplett wrote:
> On Mon, Sep 19, 2016 at 10:49:17AM -0700, Junio C Hamano wrote:
> > Andrew Donnellan <andrew.donnellan@au1.ibm.com> writes:
> >
> > > Sounds good to me. Agreed that "RFC" is essentially the only prefix
> > > other than "PATCH" that I see, at least in the kernel.
> >
> > Around here I think we saw WIP too, and that makes me lean towards
> > Peff's earlier suggestion to allow an end-user supplied string in
> > front of PATCH, i.e. "-P RFC" => "--subject-prefix='RFC PATCH'",
> > even though I understand that those who _ONLY_ care about RFC would
> > prefer --rfc (5 keystrokes) over "-P RFC" (6 keystrokes).
>
> I do share the concern raised elsewhere in the thread that adding new
> format-patch short options potentially conflicts with diff/rev-list
> short options. If you're not worried about that, I'd be happy to add
> (and document and test) -P. However, I'd still advocate adding --rfc as
> well; it's a common case, and "-P RFC" is actually rather more
> keystrokes when you count shifting. :)
>
> There might also be some value in steering people towards "RFC" (since a
> WIP is in a way an RFC).
Good point. This may be an opportunity to be just slightly opinionated
and nudge people towards a micro-standard.
I was curious what we have used over the years on the git list. So here
are the top hits for:
# start with a maildir archive
find git/cur -type f |
# grab first subject line from each mail
xargs grep -i -m1 -h ^subject: |
# pull out only bracketed text, ignore "re: [PATCH]"
perl -lne '/subject:\s*(\[.*?\])/i and print $1' |
# normalize numbers; note that a long patch series will be
# over-represented, since it gets one hit per message
perl -pe 's/[0-9]+/X/g' |
# and then sort by count
sort | uniq -c | sort -rn
The top 5 hits are:
26252 [PATCH X/X]
18255 [PATCH]
17262 [PATCH vX X/X]
2330 [PATCH vX]
2297 [PATCHvX X/X]
which is not surprising (our "-v" uses "PATCH vX", which is why that's
so much more common). After that it starts to get interesting, but let's
do two further transformations before the sort to coalesce similar
cases:
# drop versioning entirely
perl -pe 's/\s*vX//' |
# drop multipart subjects
perl -pe 's{\s*X/X}{}' |
That gives us:
67081 [PATCH]
1286 [PATCH/RFC]
1169 [RFC/PATCH]
863 [JGIT PATCH]
832 [ANNOUNCE]
797 [RFC]
675 [RFC PATCH]
537 [StGit PATCH]
524 [EGIT PATCH]
367 [BUG]
169 [StGIT PATCH]
158 [GUILT]
142 [PATCH RFC]
131 [WIP PATCH]
129 [PATCH/WIP]
115 [TopGit PATCH]
115 [PATCH VX]
...
Some of those are obviously uninteresting (like "ANNOUNCE" or "BUG").
But I see a few interesting patterns:
- the "slash" form of RFC/PATCH or PATCH/RFC seems more common than a
straight prefix (2400 versus about 800)
- both RFC/PATCH and PATCH/RFC seems similarly popular (but "RFC
PATCH" is much more popular than "PATCH RFC")
- WIP is a lot less popular; it seems reasonable that it's a synonym
for RFC and I don't mind pushing people in that direction
- 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).
So I dunno what all this means. I do think "--rfc" to standardize on
_some_ form of "RFC PATCH" or "PATCH/RFC" would serve the most people,
and would make things more consistent. But at least in Git, people would
be served by having arbitrary prefixes, too.
I don't have a big opinion on ordering or slashes. The slashes make
sense to me as "this is a patch, and it has these attribute tags" (so
we could even start saying "PATCH/maint" or something, I guess). And
"RFC" functions as such a tag. But for subsystems, putting the tag first
is probably best; I don't care about EGIT patches, so I can immediately
ignore them when it's at the beginning.
As far as your patch goes, I'd be OK with defining:
--rfc::
Pretend as if `--subject-prefix='RFC PATCH'` was given.
for now. If we later add:
-P <tag>::
Pretend as if `--subject-prefix='<tag> PATCH'` was given.
then `--rfc` naturally becomes:
--rfc::
Pretend as if `-P RFC` was given.
in a backwards-compatible way. It doesn't have to all come at once, and
it sounds like `-P` may not be as useful for the kernel (though I'd be
interested if somebody wanted to do a similar count; I don't have a copy
of the kernel archive handy).
-Peff
PS There are some amusing ones as you get far down the list, like "DRY
HUMOR PATCH". Clearly we need "-P" to encourage such things. :)
^ permalink raw reply
* Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]
From: Josh Triplett @ 2016-09-19 23:40 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Andrew Donnellan, git
In-Reply-To: <20160919233434.fhkikksi4cxzrzb5@sigill.intra.peff.net>
On Mon, Sep 19, 2016 at 04:34:35PM -0700, Jeff King wrote:
> On Mon, Sep 19, 2016 at 01:44:08PM -0700, Josh Triplett wrote:
>
> > On Mon, Sep 19, 2016 at 10:49:17AM -0700, Junio C Hamano wrote:
> > > Andrew Donnellan <andrew.donnellan@au1.ibm.com> writes:
> > >
> > > > Sounds good to me. Agreed that "RFC" is essentially the only prefix
> > > > other than "PATCH" that I see, at least in the kernel.
> > >
> > > Around here I think we saw WIP too, and that makes me lean towards
> > > Peff's earlier suggestion to allow an end-user supplied string in
> > > front of PATCH, i.e. "-P RFC" => "--subject-prefix='RFC PATCH'",
> > > even though I understand that those who _ONLY_ care about RFC would
> > > prefer --rfc (5 keystrokes) over "-P RFC" (6 keystrokes).
> >
> > I do share the concern raised elsewhere in the thread that adding new
> > format-patch short options potentially conflicts with diff/rev-list
> > short options. If you're not worried about that, I'd be happy to add
> > (and document and test) -P. However, I'd still advocate adding --rfc as
> > well; it's a common case, and "-P RFC" is actually rather more
> > keystrokes when you count shifting. :)
> >
> > There might also be some value in steering people towards "RFC" (since a
> > WIP is in a way an RFC).
>
> Good point. This may be an opportunity to be just slightly opinionated
> and nudge people towards a micro-standard.
>
> I was curious what we have used over the years on the git list. So here
> are the top hits for:
>
> # start with a maildir archive
> find git/cur -type f |
>
> # grab first subject line from each mail
> xargs grep -i -m1 -h ^subject: |
>
> # pull out only bracketed text, ignore "re: [PATCH]"
> perl -lne '/subject:\s*(\[.*?\])/i and print $1' |
>
> # normalize numbers; note that a long patch series will be
> # over-represented, since it gets one hit per message
> perl -pe 's/[0-9]+/X/g' |
>
> # and then sort by count
> sort | uniq -c | sort -rn
>
> The top 5 hits are:
>
> 26252 [PATCH X/X]
> 18255 [PATCH]
> 17262 [PATCH vX X/X]
> 2330 [PATCH vX]
> 2297 [PATCHvX X/X]
>
> which is not surprising (our "-v" uses "PATCH vX", which is why that's
> so much more common). After that it starts to get interesting, but let's
> do two further transformations before the sort to coalesce similar
> cases:
>
> # drop versioning entirely
> perl -pe 's/\s*vX//' |
>
> # drop multipart subjects
> perl -pe 's{\s*X/X}{}' |
>
> That gives us:
>
> 67081 [PATCH]
> 1286 [PATCH/RFC]
> 1169 [RFC/PATCH]
> 863 [JGIT PATCH]
> 832 [ANNOUNCE]
> 797 [RFC]
> 675 [RFC PATCH]
> 537 [StGit PATCH]
> 524 [EGIT PATCH]
> 367 [BUG]
> 169 [StGIT PATCH]
> 158 [GUILT]
> 142 [PATCH RFC]
> 131 [WIP PATCH]
> 129 [PATCH/WIP]
> 115 [TopGit PATCH]
> 115 [PATCH VX]
> ...
>
> Some of those are obviously uninteresting (like "ANNOUNCE" or "BUG").
> But I see a few interesting patterns:
>
> - the "slash" form of RFC/PATCH or PATCH/RFC seems more common than a
> straight prefix (2400 versus about 800)
>
> - both RFC/PATCH and PATCH/RFC seems similarly popular (but "RFC
> PATCH" is much more popular than "PATCH RFC")
>
> - WIP is a lot less popular; it seems reasonable that it's a synonym
> for RFC and I don't mind pushing people in that direction
>
> - 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.
> As far as your patch goes, I'd be OK with defining:
>
> --rfc::
> Pretend as if `--subject-prefix='RFC PATCH'` was given.
>
> for now. If we later add:
>
> -P <tag>::
> Pretend as if `--subject-prefix='<tag> PATCH'` was given.
>
> then `--rfc` naturally becomes:
>
> --rfc::
> Pretend as if `-P RFC` was given.
>
> in a backwards-compatible way. It doesn't have to all come at once, and
> it sounds like `-P` may not be as useful for the kernel (though I'd be
> interested if somebody wanted to do a similar count; I don't have a copy
> of the kernel archive handy).
Sounds reasonable to me. I'll send v3 of --rfc with the requested
additional documentation fix, then.
^ permalink raw reply
* Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]
From: Jacob Keller @ 2016-09-19 23:44 UTC (permalink / raw)
To: Jeff King
Cc: Josh Triplett, Junio C Hamano, Andrew Donnellan, Git mailing list
In-Reply-To: <20160919233434.fhkikksi4cxzrzb5@sigill.intra.peff.net>
On Mon, Sep 19, 2016 at 4:34 PM, Jeff King <peff@peff.net> 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).
Working in the net-next community, we often use "[net PATCH]",
"[net-next] [PATCH]", or even just replace "PATCH" with "[net-next]"
and similar (though this is served just fine by --subject-prefix, and
may be an artifact caused because -P doesn't exist).
For the netdev, there are both "net" and "net-next" trees, and so
there is some need to distinguish between these. I prefer "[net
PATCH]" style myself.
I think --rfc is common enough to warrant its own tag, even if we add
"-P tag" just because it encourages its use for whenever you want to
comment about a patch without necessarily wanting it immediately
applied.
I also happen to prefer "RFC PATCH" instead of "PATCH/RFC" but I think
that's mostly preference.
>
> So I dunno what all this means. I do think "--rfc" to standardize on
> _some_ form of "RFC PATCH" or "PATCH/RFC" would serve the most people,
> and would make things more consistent. But at least in Git, people would
> be served by having arbitrary prefixes, too.
>
A general way to do this would be helpful, but i don't think it avoids
the usefulness of --rfc on its own.
I know that some formats are also generated by tools such as stgit
which has its own way to generate emails and doesn't use exactly the
same format as git.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]
From: Jacob Keller @ 2016-09-19 23:46 UTC (permalink / raw)
To: Josh Triplett
Cc: Jeff King, Junio C Hamano, Andrew Donnellan, Git mailing list
In-Reply-To: <20160919234022.GA29421@cloud>
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.
That being said, I'm not super strongly against it, but just find that
it sounds weird for documentation.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]
From: Josh Triplett @ 2016-09-19 23:55 UTC (permalink / raw)
To: Jacob Keller
Cc: Jeff King, Junio C Hamano, Andrew Donnellan, Git mailing list
In-Reply-To: <CA+P7+xp-CupfFwQv+U-KNh4bxG9Mxkbfip5RJebKX9gjffoOsw@mail.gmail.com>
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. :)
^ permalink raw reply
* 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
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