Re: [PATCH v2] format-patch: respect --stat in cover letter's diffstat

2018-11-12 Thread Laszlo Ersek
gt; width will be 72 (ignoring $COLUMNS, but could still be overriden by > --stat). So all we need to do here is drop the assignment. > > Reported-by: Laszlo Ersek > Helped-by: Leif Lindholm > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > builtin/lo

Re: [PATCH v2] format-patch: respect --stat in cover letter's diffstat

2018-11-07 Thread Laszlo Ersek
gt; width will be 72 (ignoring $COLUMNS, but could still be overriden by > --stat). So all we need to do here is drop the assignment. > > Reported-by: Laszlo Ersek > Helped-by: Leif Lindholm > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > builtin/lo

Re: [PATCH] format-patch: respect --stat when explicitly specified

2018-11-06 Thread Laszlo Ersek
er-letter files. >> >> Cc: Nguyễn Thái Ngọc Duy >> Cc: Junio C Hamano >> Reported-by: Laszlo Ersek >> Signed-off-by: Leif Lindholm >> --- >> >> Note: >> In TianoCore we have LotsOfGloriousFilesNamedInReallyLongCamelCase, so >> our offi

Re: recent glob expansion breakage on Windows?

2018-03-09 Thread Laszlo Ersek
On 03/08/18 23:03, Jonathan Nieder wrote: > +git-for-windows > Hi, > > Laszlo Ersek wrote: > >> Jaben reports that git-send-email is suddenly failing to expand the >> "*.patch" glob for him, at the Windows CMD prompt: >> >> - >> E

recent glob expansion breakage on Windows?

2018-03-08 Thread Laszlo Ersek
Hi, Jaben reports that git-send-email is suddenly failing to expand the "*.patch" glob for him, at the Windows CMD prompt: - E:\...>git send-email --suppress-cc=author --suppress-cc=self --suppress-cc=cc --suppress-cc=sob --dry-run *.patch No patch files specified! - Whereas,

Re: FORMAT_PATCH_NAME_MAX increase

2017-05-30 Thread Laszlo Ersek
On 05/30/17 16:35, Ævar Arnfjörð Bjarmason wrote: > On Tue, May 30, 2017 at 3:37 PM, Junio C Hamano wrote: >> Ævar Arnfjörð Bjarmason writes: >> >>> Just curious do you know about https://github.com/trast/tbdiff ? If >>> not it might have a high overlap with

Re: FORMAT_PATCH_NAME_MAX increase

2017-05-30 Thread Laszlo Ersek
(apologies for the self-followup:) On 05/30/17 14:28, Laszlo Ersek wrote: > Note that in such an incremental review, I specifically wish to compare > patches against each other (i.e., I'd like to see diffs of diffs, AKA > interdiffs), and not the source tree at two, v1<-

Re: FORMAT_PATCH_NAME_MAX increase

2017-05-30 Thread Laszlo Ersek
On 05/30/17 13:36, Ævar Arnfjörð Bjarmason wrote: > On Mon, May 29, 2017 at 10:49 AM, Laszlo Ersek <ler...@redhat.com> wrote: >> Hi, >> >> would it be possible to >> >> - increase the FORMAT_PATCH_NAME_MAX macro from 64 to, say, 128? >> &g

Re: FORMAT_PATCH_NAME_MAX increase

2017-05-30 Thread Laszlo Ersek
On 05/30/17 03:34, Junio C Hamano wrote: > I cannot offhand guess what other places would suffer from such a > project convention, because I do not work with such a project, but > you may be able to come up with a list of various places in Git > where the commit titles are used, and that if there

FORMAT_PATCH_NAME_MAX increase

2017-05-29 Thread Laszlo Ersek
Hi, would it be possible to - increase the FORMAT_PATCH_NAME_MAX macro from 64 to, say, 128? - Or else to introduce a new git-config knob for it? I have a small review-helper / interdiff script that matches patches from adjacent versions of a series against each other, based on subject line.

Re: appending a pattern to the default "diff.cpp.xfuncname"

2016-08-03 Thread Laszlo Ersek
On 08/03/16 20:02, Jeff King wrote: > On Wed, Aug 03, 2016 at 12:16:14PM +0200, Laszlo Ersek wrote: > >> I've used diff..xfuncname with great success for file s that >> I defined myself. However, now I would like to append an extra pattern >> to the TYPE=cpp case (f

appending a pattern to the default "diff.cpp.xfuncname"

2016-08-03 Thread Laszlo Ersek
Hi, I've used diff..xfuncname with great success for file s that I defined myself. However, now I would like to append an extra pattern to the TYPE=cpp case (for which git has builtin patterns). Is there an easy way to do this? I figured I could open-code the builtin patterns from "userdiff.c",

Re: [PATCH for-maint] apply: gitdiff_verify_name(): accept /dev/null\r

2014-09-24 Thread Laszlo Ersek
On 09/23/14 23:35, Junio C Hamano wrote: Laszlo Ersek ler...@redhat.com writes: [...] The important thing to note here is that use of text/plain for patches, if you want to have distinction between CRLF and LF in your payload, is not designed to work over e-mails. That's good to know

Re: [PATCH for-maint] apply: gitdiff_verify_name(): accept /dev/null\r

2014-09-23 Thread Laszlo Ersek
On 09/23/14 20:54, Junio C Hamano wrote: Laszlo Ersek ler...@redhat.com writes: git format-patch master..branch1 The output from this has these (excerpt from od -xc output): 360 f 2 \n \n d i f f - - g i t 66200a32640a6669

Re: [PATCH for-maint] apply: gitdiff_verify_name(): accept /dev/null\r

2014-09-23 Thread Laszlo Ersek
On 09/23/14 22:02, Junio C Hamano wrote: Laszlo Ersek ler...@redhat.com writes: On 09/23/14 20:54, Junio C Hamano wrote: ... SMTP transport may be CRLF-unsafe, so I have a suspicion that it may turn out that what you are trying to do might be an equilvalent of git format-patch

Re: [PATCH for-maint] apply: gitdiff_verify_name(): accept /dev/null\r

2014-09-23 Thread Laszlo Ersek
On 09/23/14 21:56, Junio C Hamano wrote: Laszlo Ersek ler...@redhat.com writes: What do you think about accepting only /dev/null\n and /dev/null\r\n? I thought we agreed that what you are doing is not workable in the first place, no? I suspect one way to handle In this project

Re: [PATCH for-maint] apply: gitdiff_verify_name(): accept /dev/null\r

2014-09-23 Thread Laszlo Ersek
On 09/23/14 22:35, Junio C Hamano wrote: Laszlo Ersek ler...@redhat.com writes: On 09/23/14 22:02, Junio C Hamano wrote: Laszlo Ersek ler...@redhat.com writes: On 09/23/14 20:54, Junio C Hamano wrote: ... SMTP transport may be CRLF-unsafe, so I have a suspicion that it may turn out

Re: [PATCH for-maint] apply: gitdiff_verify_name(): accept /dev/null\r

2014-09-23 Thread Laszlo Ersek
On 09/23/14 22:40, Junio C Hamano wrote: Laszlo Ersek ler...@redhat.com writes: On 09/23/14 21:56, Junio C Hamano wrote: Laszlo Ersek ler...@redhat.com writes: What do you think about accepting only /dev/null\n and /dev/null\r\n? I thought we agreed that what you are doing is not workable

[PATCH for-maint] apply: gitdiff_verify_name(): accept /dev/null\r

2014-09-22 Thread Laszlo Ersek
in effect changes the condition from memcmp(/dev/null, line, 9) || line[9] != '\n' to memcmp(/dev/null, line, 9) || !isspace(line[9]) Signed-off-by: Laszlo Ersek ler...@redhat.com --- Notes: I'm not subscribed to the list; please keep me CC'd. Thanks. builtin/apply.c | 2 +- 1 file