On Tue, Aug 16, 2016 at 10:10 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>
>> So as a discussion starter:
>> * Should git am skip a patch 00/XX automatically ?
>
> No. My preference is to add "--initial-skip=<N>", though.
>
> When I receive a patch series to reroll another series, I somehow
> know and verify that earlier N patches have not changed, I detach
> the HEAD at the last unchanged commit from the previous round and
> apply the remainder of the new series, so that I can preserve the
> author timestamps of earlier steps from the previous series. By
> the time I "know and verify" where the first step that was updated,
> I have a full series in a single mbox; having "--initial-skip=<N>"
> would help with that use case, too, and "skipping the first" is a
> narrow special case of giving N=1.
In your work flow, how do you respect the cover letter?
e.g. in 3787e3c16ced:
Merge branch 'ew/http-backend-batch-headers'
The http-backend (the server-side component of smart-http
transport) used to trickle the HTTP header one at a time. Now
these write(2)s are batched.
* ew/http-backend-batch-headers:
http-backend: buffer headers before sending
Is the text from the original author (and if so from which version
of the cover letter) or is it your work?
>
>> * Should the public-inbox offer another link to patches 1-n, without
>> the cover letter? Or should it add instructions:
>>
>> If this is a patch series you can apply it locally as:
>> curl <link> >tmpXXX
>> git am tmpXXX && git am --skip && git am --continue
>
> I do not think it is sensible for "cover-letter" specific
> instructions. However, I do not think it is unreasonable to either
> add another mbox.gz link or replace the behaviour of mbox.gz link so
> that you can grab a mbox that contains "this message and everything
> after it in the thread". That way, I could open the first message,
> see something like this I found in your message:
>
>>> Thread overview: 4+ messages in thread (expand / mbox.gz / Atom feed / [top])
>>> 2016-08-15 23:06 Jacob Keller [this message]
>>> 2016-08-15 23:07 ` [PATCH v6 1/3] diff.c: remove output_prefix_length field Jacob Keller
>>> 2016-08-15 23:07 ` [PATCH v6 2/3] graph: add support for --line-prefix on all graph-aware output Jacob Keller
>>> 2016-08-15 23:07 ` [PATCH v6 3/3] diff: add SUBMODULE_DIFF format to display submodule diff Jacob Keller
>
> and then go to 1/3 and click that "this and everything that
> follows".
Both thoughts are sensible; However the --initial-skip=<n>
doesn't address the special case of storing the cover letter
(which we eventually want to do?)
I thought of it as the following with room for improvement:
diff --git a/builtin/am.c b/builtin/am.c (shite space broken):
index 739b34d..5f08b61 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -1246,6 +1246,7 @@ static int parse_mail(struct am_state *state,
const char *mail)
FILE *fp;
struct strbuf sb = STRBUF_INIT;
struct strbuf msg = STRBUF_INIT;
+ struct strbuf subject = STRBUF_INIT;
struct strbuf author_name = STRBUF_INIT;
struct strbuf author_date = STRBUF_INIT;
struct strbuf author_email = STRBUF_INIT;
@@ -1309,6 +1310,7 @@ static int parse_mail(struct am_state *state,
const char *mail)
if (msg.len)
strbuf_addch(&msg, '\n');
strbuf_addstr(&msg, x);
+ strbuf_addstr(&subject, x);
} else if (skip_prefix(sb.buf, "Author: ", &x))
strbuf_addstr(&author_name, x);
else if (skip_prefix(sb.buf, "Email: ", &x))
@@ -1325,8 +1327,17 @@ static int parse_mail(struct am_state *state,
const char *mail)
}
if (is_empty_file(am_path(state, "patch"))) {
- printf_ln(_("Patch is empty. Was it split wrong?"));
- die_user_resolve(state);
+ if (indicates_coverletter(&subject))
+ /*
+ * TODO: store the cover letter as the first or last
+ * commit or as branch.<name>.description
+ */
+ ret = 1;
+ goto finish;
+ else {
+ printf_ln(_("Patch is empty. Was it split wrong?"));
+ die_user_resolve(state);
+ }
}
strbuf_addstr(&msg, "\n\n");
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html