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
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
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
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
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,
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
(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<-
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
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
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.
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
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",
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
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
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
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
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
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
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
19 matches
Mail list logo