(replying from webmail interface)
On Fri, Sep 5, 2014 at 3:25 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Redoing what e3f67d30 (am: fix patch format detection for
Thunderbird Save As emails, 2010-01-25) tried to do without
wasting a fork and a pipe
Can we throw up a big warning or just outright fail if someone types
'n' or 'y' and hits enter for the in-reply-to question in
git-send-email? I saw a git-send-email sent patch with an In-Reply-To
header containing n on lkml today and it makes threading in my mail
client get confused.
On Tue, Aug 14, 2012 at 3:25 PM, Junio C Hamano gits...@pobox.com wrote:
@@ -745,13 +752,15 @@ sub file_declares_8bit_cte {
if (!defined $sender) {
$sender = $repoauthor || $repocommitter || '';
$sender = ask(Who should the emails appear to be from? [$sender] ,
-
(Sorry sending this from web interface)
On Wed, Sep 5, 2012 at 8:29 PM, Junio C Hamano gits...@pobox.com wrote:
Stephen Boyd bebar...@gmail.com writes:
This is now bugging me if I just hit enter and don't want to specify
anything for
these headers (I want the defaults or what's in the files
On Thu, Sep 6, 2012 at 1:03 PM, Junio C Hamano gits...@pobox.com wrote:
If you let $to to go empty with the first hunk of your patch, where
does the mail eventually go? Does anybody later in the code decide
to add some recipient? If there is a reason why an empty input is a
valid here, I
without replying to anything, and it is
valid to leave $initial_reply_to empty.
An earlier update to avoid y...@example.com stuffed in address fields
did not take these two cases into account.
Noticed and fix suggested by Stephen Boyd.
Signed-off-by: Junio C Hamano gits...@pobox.com
While running --show-signatures on the linux kernel I noticed that after
a while git failed with an error message indicating it had run out of
file descriptors. The first patch fixes this problem, and the next
two are randmom bits since I was in the area.
Stephen Boyd (3):
gpg: Close stderr
with
error: cannot create pipe for gpg: Too many open files
error: could not run gpg.
Close the stderr pipe so that this can't happen.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
gpg-interface.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gpg-interface.c b/gpg-interface.c
index
Mark these strings for translation so that error messages are
printed in the user's language of choice.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
gpg-interface.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gpg-interface.c b/gpg-interface.c
index 2c0bed3
in the error message so we
can more easily debug similar problems in the future.
For example, the above error now prints:
error: cannot create stderr pipe for gpg: Too many open files
error: could not run gpg.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
run-command.c | 8 ++--
1
On 01/31/13 08:24, Junio C Hamano wrote:
Stephen Boyd sb...@codeaurora.org writes:
While debugging an error with verify_signed_buffer() the error
messages from run-command weren't very useful:
error: cannot create pipe for gpg: Too many open files
error: could not run gpg.
because
On 01/30/13 21:50, Jeff King wrote:
The strbuf_read above will read to EOF, so it should be equivalent (and
IMHO slightly more readable) to do:
diff --git a/gpg-interface.c b/gpg-interface.c
index 0863c61..5f142f6 100644
--- a/gpg-interface.c
+++ b/gpg-interface.c
@@ -130,8 +130,10 @@ int
with
error: cannot create pipe for gpg: Too many open files
error: could not run gpg.
Close the stderr pipe so that this can't happen.
Suggested-by: Jeff King p...@peff.net
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
gpg-interface.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
I ran into these bugs the other day and didn't have time to
investigate further. So I wrote test cases for them instead.
Stephen Boyd (2):
t3501: Expose bug with cherry-pick into dirty trees w/ renames
t3501: Expose addinfo_cache error message in cherry-pick
t/t3501-revert-cherry-pick.sh
the cherry-pick.
error: addinfo_cache failed for path 'otherfile'
I suspect this error message shouldn't be printed, so recreate
the problem in t3501 so that it can be fixed.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
t/t3501-revert-cherry-pick.sh | 32
-by: Stephen Boyd sb...@codeaurora.org
---
t/t3501-revert-cherry-pick.sh | 28
1 file changed, 28 insertions(+)
diff --git a/t/t3501-revert-cherry-pick.sh b/t/t3501-revert-cherry-pick.sh
index 6f489e2..eef4d8c 100755
--- a/t/t3501-revert-cherry-pick.sh
+++ b/t/t3501-revert
Hi,
I was trying git am -3 with a patch that touched files that didn't exist
in the branch I was on. Obviously it failed badly, so I wanted to abort
out of the git am state with git am --abort. Unfortunately, it seems
that git am --abort in this scenario fails with this error:
error: cache entry
On 02/11/13 20:27, Stephen Boyd wrote:
I ran into these bugs the other day and didn't have time to
investigate further. So I wrote test cases for them instead.
Stephen Boyd (2):
t3501: Expose bug with cherry-pick into dirty trees w/ renames
t3501: Expose addinfo_cache error message
(resending since the attachment seems to make vger sad)
Hi,
I'm running git rev-list | git cherry-pick --stdin on a range of about
300 commits. Eventually the chery-pick dies with:
error: cannot fork() for commit: Cannot allocate memory
Running valgrind shows me that the tree traversal
On 04/30/13 15:47, René Scharfe wrote:
Am 30.04.2013 02:11, schrieb Stephen Boyd:
(resending since the attachment seems to make vger sad)
Hi,
I'm running git rev-list | git cherry-pick --stdin on a range of about
300 commits. Eventually the chery-pick dies with:
error: cannot fork
On 04/30/13 15:47, René Scharfe wrote:
Am 30.04.2013 02:11, schrieb Stephen Boyd:
(resending since the attachment seems to make vger sad)
Hi,
I'm running git rev-list | git cherry-pick --stdin on a range of about
300 commits. Eventually the chery-pick dies with:
error: cannot fork
On 05/09/13 08:10, René Scharfe wrote:
Am 06.05.2013 22:16, schrieb Stephen Boyd:
Ok. I tested it and it definitely helps.
==10728== LEAK SUMMARY:
==10728==definitely lost: 316,355,458 bytes in 8,652 blocks
==10728==indirectly lost: 1,327,251,588 bytes in 16,180,628 blocks
==10728
22 matches
Mail list logo
