Re: git grep with leading inverted bracket expression

On Thu, Jun 07, 2018 at 09:09:25PM +0200, Ævar Arnfjörð Bjarmason wrote: > On Thu, Jun 07 2018, Matthew Wilcox wrote: > > If the first atom of a regex is a bracket expression with an inverted range, > > git grep is very slow. > > I have some WIP patches to fix all of this,

git grep with leading inverted bracket expression

If the first atom of a regex is a bracket expression with an inverted range, git grep is very slow. $ time git grep 'struct_size' >/dev/null real0m0.368s user0m0.563s sys 0m0.453s $ time git grep '[^t]truct_size' >/dev/null real0m31.529s user1m54.909s sys 0m0.805s If

Re: [PATCH] git-send-email: Cc more people

On Thu, Apr 19, 2018 at 06:21:42AM +0900, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > But IMO this patch is really lacking a few things before being ready: > > > > 1. You have no tests for this. See t/t9001-send-email.sh for examples, > > ... > > 2. Just a few

[PATCH] git-send-email: Cc more people

From: Matthew Wilcox <mawil...@microsoft.com> Several of my colleagues (and myself) have expressed surprise and annoyance that git-send-email doesn't automatically pick up people who are listed in patches as Reported-by: or Reviewed-by: or ... many other tags that would seem (to us) to in

Re: [PATCH] enable core.fsyncObjectFiles by default

On Wed, Jan 17, 2018 at 11:04:32AM -0800, Junio C Hamano wrote: > Christoph Hellwig writes: > > @@ -866,10 +866,8 @@ core.whitespace:: > > core.fsyncObjectFiles:: > > This boolean will enable 'fsync()' when writing object files. > > + > > -This is a total waste of time and

git send-email could check for no To: line

I keep coming up with new and innovative ways to send stupid-looking emails with git send-email. Please save me from myself. My latest SNAFU is to spend so much time setting up the 'cc' list in the git-format-patch step that I completely forgot to put anybody on the 'to' line, and even being

RE: [PATCH 2/2] mailinfo: Understand forwarded patches

From: Jonathan Tan [mailto:jonathanta...@google.com] > On 01/12/2017 01:20 AM, Matthew Wilcox wrote: > > From: Matthew Wilcox <mawil...@microsoft.com> > > > > Extend the --scissors mechanism to strip off the preamble created by > > forwarding a patch. There are

RE: [PATCH 1/2] mailinfo: Add support for keep_cr

From: Jonathan Tan [mailto:jonathanta...@google.com] > On 01/12/2017 01:20 AM, Matthew Wilcox wrote: > A test exercising the new functionality would be nice. Roger. > Also, maybe a more descriptive title like "mailinfo: also respect > keep_cr after base64 decode" (50

[PATCH 1/2] mailinfo: Add support for keep_cr

From: Matthew Wilcox <mawil...@microsoft.com> If you have a base-64 encoded patch with CRLF endings (as produced by forwarding a patch from Outlook to a Linux machine, for example), the keep_cr setting is not honoured because keep_cr is only passed to mailsplit, which does not look t

[PATCH 2/2] mailinfo: Understand forwarded patches

From: Matthew Wilcox <mawil...@microsoft.com> Extend the --scissors mechanism to strip off the preamble created by forwarding a patch. There are a couple of extra headers ("Sent" and "To") added by forwarding, but other than that, the --scissors option will now rem