o be useful to run
--edit-todo if you realize your rebase strategy needs to change partway
through a rebase which was initially non-interactive.
Note: I'm a non-subscriber, please Cc me on replies.
--
Drew DeVault
Thanks for clarifying this, folks.
On 2019-04-17 6:11 PM, Johannes Schindelin wrote:
> To my surprise, Elijah Newren (who authored that change) then demonstrated
> that in most cases, the `--merge` backend is actually *faster* than the
> default (`--am`) backend. There were patches floating aroun
I want to gather some thoughts about this. Say you've written a patch
series and are getting ready to send a -v2. If you set
--in-reply-to=ask, it'll show you a list of emails you've recently sent,
and their subject lines, and ask you to pick one to use the message ID
from. It'll set the In-Reply-T
On 2019-05-08 5:19 PM, Emily Shaffer wrote:
> What I think might be useful (and what I was hoping you were going to
> talk about when I saw the subject line) would be if the Message-Id is
> conveniently stored during `git send-email` on v1 and somehow saved in a
> useful place in order to apply to
On 2019-05-09 11:51 AM, Emily Shaffer wrote:
> I'm still not sure I see the value of the extra header proposed here.
> I'd appreciate an explanation of how you think it would be used, Drew.
I'm not just thinking about your run of the mill mail reader, but also
mail readers which are aware of git a
This flag would behave similarly to git apply --check, or in other words
would exit with a nonzero status if the patch is not applicable without
actually applying the patch otherwise.
Rationale: I'm working on an email client which has some git
integration, and when you scroll over a patch I want
---
Documentation/git-am.txt | 7 ++-
builtin/am.c | 13 +
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index fc3b993c33..bc01e87d85 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.t
in a very long time which doesn't support
extended SMTP. The default behavior should probably change. If not, the
error message should be more clear about action items to address the
issue.
I'll send a patch around to change this shortly.
--
Drew DeVault
On 2018-07-01 6:15 PM, brian m. carlson wrote:
> Can you say a bit more about the exact error message you're seeing?
"patch contains a line longer than 998 characters"
A recent occasion when this came up was when someone attempted to send
me a patch which included a base64-encoded data URI, whic
I seem to be mistaken about the degree to which this is standardized and
supported. The Debian argument cinches it for me. Quoted printable is
probably the right way to go, then.
On 2018-07-06 2:23 AM, brian m. carlson wrote:
> diff --git a/git-send-email.perl b/git-send-email.perl
> index a76953c310..4ea30c4070 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1899,6 +1899,10 @@ sub validate_patch {
> return $hook_error if $hook_error;
>
Overall this series looks good. Thanks for putting the patches together!
LGTM, thanks for the v2.
When shown the email summary, an opportunity is presented for the user
to edit the email as if they had specified --annotate. This also permits
them to edit it multiple times.
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
---
git-send-email.perl | 35 ---
1
When shown the email summary, an opportunity is presented for the user
to edit the email as if they had specified --annotate. This also permits
them to edit it multiple times.
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
---
Sent to the ML without comment, sending back around with more
When shown the email summary, an opportunity is presented for the user
to edit the email as if they had specified --annotate. This also permits
them to edit it multiple times.
Signed-off-by: Drew DeVault
Reviewed-by: Simon Ser
---
Thanks for the review Eric, updated to address your feedback
16 matches
Mail list logo
