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", a
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 ca
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
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
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, mo
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,
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. (U
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
On 05/30/17 13:36, Ævar Arnfjörð Bjarmason wrote:
> On Mon, May 29, 2017 at 10:49 AM, Laszlo Ersek wrote:
>> Hi,
>>
>> would it be possible to
>>
>> - increase the FORMAT_PATCH_NAME_MAX macro from 64 to, say, 128?
>>
>> - Or else to introduce a new
(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 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 what you're doing.
Thank you for the
name().
Fix it by reusing the is_dev_null() helper function, which 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
---
Notes:
I'm not s
On 09/23/14 20:54, Junio C Hamano wrote:
> Laszlo Ersek 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
>
On 09/23/14 22:02, Junio C Hamano wrote:
> Laszlo Ersek 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 equilva
On 09/23/14 21:56, Junio C Hamano wrote:
> Laszlo Ersek 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 suspec
On 09/23/14 22:35, Junio C Hamano wrote:
> Laszlo Ersek writes:
>
>> On 09/23/14 22:02, Junio C Hamano wrote:
>>> Laszlo Ersek writes:
>>>
>>>> On 09/23/14 20:54, Junio C Hamano wrote:
>>>> ...
>>>>> SMTP transport may be CR
On 09/23/14 22:40, Junio C Hamano wrote:
> Laszlo Ersek writes:
>
>> On 09/23/14 21:56, Junio C Hamano wrote:
>>> Laszlo Ersek writes:
>>>
>>>> What do you think about accepting only "/dev/null\n" and "/dev/null\r\n"?
>>>
On 09/23/14 23:35, Junio C Hamano wrote:
> Laszlo Ersek 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&#
19 matches
Mail list logo
