On Fri, 2018-03-23 at 08:38 +0100, Dominik Brodowski wrote:
> On Thu, Mar 22, 2018 at 10:44:54AM -0700, Linus Torvalds wrote:
> > On Thu, Mar 22, 2018 at 10:29 AM, Peter Zijlstra
> > wrote:
> > >
> > > But why !? Either Cc me on more of the series such that the whole makes
On Sat, 2017-10-28 at 00:11 +0200, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Oct 27 2017, Joe Perches jotted:
[]
> > git grep performance has already been
> > quite successfully improved.
>
> ...and I have WIP patches to use the PCRE engine for patterns without -P
> which I
On Thu, 2017-10-26 at 10:45 -0700, Stefan Beller wrote:
> On Thu, Oct 26, 2017 at 10:41 AM, Joe Perches <j...@perches.com> wrote:
> > On Thu, 2017-10-26 at 09:58 -0700, Stefan Beller wrote:
> > > + Avar who knows a thing about pcre (I assume the regex compilation
> &
On Thu, 2017-10-26 at 09:58 -0700, Stefan Beller wrote:
> + Avar who knows a thing about pcre (I assume the regex compilation
> has impact on grep speed)
>
> On Thu, Oct 26, 2017 at 8:02 AM, Joe Perches <j...@perches.com> wrote:
> > Comparing a cache warm git grep vs com
On Thu, 2017-10-26 at 18:13 +0200, SZEDER Gábor wrote:
> > Comparing a cache warm git grep vs command line grep
> > shows significant differences in cpu & wall clock.
> >
> > Any ideas how to improve this?
> >
> > $ time git grep "\bseq_.*%p\W" | wc -l
> > 112
> >
> > real0m4.271s
> >
On Thu, 2017-10-26 at 17:11 +0200, Han-Wen Nienhuys wrote:
> On Thu, Oct 26, 2017 at 5:02 PM, Joe Perches <j...@perches.com> wrote:
> > Comparing a cache warm git grep vs command line grep
> > shows significant differences in cpu & wall clock.
> >
> > Any i
Comparing a cache warm git grep vs command line grep
shows significant differences in cpu & wall clock.
Any ideas how to improve this?
$ time git grep "\bseq_.*%p\W" | wc -l
112
real0m4.271s
user0m15.520s
sys 0m0.395s
$ time grep -r --include=*.[ch] "\bseq_.*%p\W" * | wc -l
112
On Thu, 2017-01-19 at 15:42 -0800, Jacob Keller wrote:
> On Thu, Jan 19, 2017 at 1:20 PM, Jeff King wrote:
> > On Thu, Jan 19, 2017 at 09:43:45PM +0100, Wolfram Sang wrote:
> >
> > > > As to the implementation, I am wondering if we can make this somehow
> > > > work well with the
On Thu, 2016-12-15 at 21:00 -0800, Junio C Hamano wrote:
> Joe Perches <j...@perches.com> writes:
>
> > grep 2.5.4 was the last version that supported the -P option to
> > grep through for multiple lines.
>
> Does anybody know why it was dropped?
perl compatible re
On Thu, 2016-12-15 at 18:10 -0800, Linus Torvalds wrote:
> On Thu, Dec 15, 2016 at 5:57 PM, Joe Perches <j...@perches.com> wrote:
> > >
> > > In fact, I thought we already upped the check-patch limit to 100?
> >
> > Nope, CodingStyle neither.
> >
On Wed, 2016-08-31 at 12:34 -0700, Junio C Hamano wrote:
> Joe Perches <j...@perches.com> writes:
> > Many commits have various forms of bylines similar to
> A missing blank line (I can tweak while queuing).
[]
> > + next if $suppress
Many commits have various forms of bylines similar to
"Acked-by: Name " and "Reported-by: Name "
Add the ability to cc: bylines (e.g. Acked-by:) when using git send-email.
This can be suppressed with --suppress-cc=bylines.
Signed-off-by: Joe Perches <j...@perches.
On Wed, 2016-08-31 at 10:54 -0700, Junio C Hamano wrote:
> Joe Perches <j...@perches.com> writes:
> >
> > Many commits have various forms of trailers similar to
> > "Acked-by: Name " and "Reported-by: Name "
> >
> > Add the ability
On Wed, 2016-08-31 at 10:54 -0700, Junio C Hamano wrote:
> Joe Perches <j...@perches.com> writes:
>
> >
> > Many commits have various forms of trailers similar to
> > "Acked-by: Name " and "Reported-by: Name "
> >
> > Add t
Many commits have various forms of trailers similar to
"Acked-by: Name " and "Reported-by: Name "
Add the ability to cc these trailers when using git send-email.
This can be suppressed with --suppress-cc=trailers.
Signed-off-by: Joe Perches <j...@perches.com>
-
On Tue, 2016-08-30 at 11:17 -0700, Junio C Hamano wrote:
> Joe Perches <j...@perches.com> writes:
>
> >
> > On Tue, 2016-08-30 at 10:41 -0700, Joe Perches wrote:
> > >
> > > Maybe something like traces or chains.
> > Or "taggers" or &quo
(adding lkml)
On Tue, 2016-08-30 at 09:54 -0700, Junio C Hamano wrote:
> Joe Perches <j...@perches.com> writes:
> > git-am -s will avoid duplicating the last signature
> > in a patch.
> >
> > But given a developer creates a patch, send it around for
> > a
On Sun, 2016-08-28 at 23:24 +0200, Dennis Kaarsemaker wrote:
> > There are some that want an ncurses only version of git blame
> > that could use arrow-key style navigation for historical commit
> > line-ranges.
> >
> > git gui blame kind of works, but it's not ncurses/text based.
> > git-cola
On Sun, 2016-08-28 at 11:59 +0200, Julia Lawall wrote:
> On Sun, 28 Aug 2016, Alexey Dobriyan wrote:
[]
> > The problem is that c-h.pl generates noise in the commit history and
> > makes git-blame less useful than it can be.
>
> Could it be that this is a problem with git blame, rather than with
On Wed, 2016-08-03 at 00:17 +0200, Florian Mickler wrote:
> cc'd mche...@s-opensource.com (Mauro, is your kernel.org address up?)
>
> Am Tue, 02 Aug 2016 09:36:21 -0700
> schrieb Joe Perches <j...@perches.com>:
>
> >
> > Hello Florian.
> > There is
Hello Florian.
There is at least an oddity with get_maintainer handling of a
.mailmap entry form.
For instance:
Mauro's .mailmap entry is:
Mauro Carvalho Chehab
On Wed, 2015-12-02 at 09:58 -0800, Junio C Hamano wrote:
> "Trailers" are not limited to "*-by:"
btw: what are "Trailers" limited by?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
quot;CC:" entries.
Add command line option --suppress-cc=signatures to avoid
adding these entries to the cc.
Signed-off-by: Joe Perches perches.com>
Acked-by: Jeff Kirsher intel.com>
---
> It's been four years, but I recently ran into this. I mistakenly thought
> that git would
On Wed, 2015-12-02 at 09:58 -0800, Junio C Hamano wrote:
> Joe Perches <j...@perches.com> writes:
>
> > Many types of signatures are used by various projects.
> >
> > The most common type is formatted:
> > "[some_signature_type]-by: First Last
On Wed, 2014-11-05 at 22:12 +1300, Chris Packham wrote:
On Wed, Nov 5, 2014 at 2:12 PM, Joe Perches j...@perches.com wrote:
I have a patch file created by git format-patch.
[]
ASoC:? where does that come from?
[]
Looks like you have an apply-patch-msg hook installed. What does the
output
neatening
Use a more common logging style.
o Convert DEBUG macros to pr_debug
o Add pr_fmt
o Remove embedded function names from pr_debug
o Convert printks to pr_level
o Coalesce formats and align arguments
o Add missing terminating newlines
Signed-off-by: Joe Perches j...@perches.com
On Thu, 2014-09-25 at 17:03 +0200, Greg Kroah-Hartman wrote:
In the future, please generate a git move diff, which makes it easier
to review, and prove that nothing really changed. It also helps if the
file is a bit different from what you diffed against, which in my case,
was true.
Maybe
On Thu, 2014-09-25 at 14:00 -0400, Jeff King wrote:
On Thu, Sep 25, 2014 at 08:48:31AM -0700, Joe Perches wrote:
On Thu, 2014-09-25 at 17:03 +0200, Greg Kroah-Hartman wrote:
In the future, please generate a git move diff, which makes it easier
to review, and prove that nothing really
On Sun, 2014-08-10 at 23:08 +0200, Geert Uytterhoeven wrote:
Hi Joe,
Hi Geert.
On Thu, Jul 3, 2014 at 12:00 AM, Joe Perches j...@perches.com wrote:
Commit logs have various forms of commit id references.
Try to standardize on a 12 character long lower case
commit id along
On Sun, 2014-08-10 at 14:35 -0700, Andrew Morton wrote:
On Sun, 10 Aug 2014 14:28:01 -0700 Joe Perches j...@perches.com wrote:
On Thu, Jul 3, 2014 at 12:00 AM, Joe Perches j...@perches.com wrote:
Commit logs have various forms of commit id references.
Try to standardize on a 12
Hi.
Is there something that can be done about improving
git log --follow -- file performance to be nearly
equivalent speed to git blame -- file ?
The overall cpu time taken for these 2 commands that
track individual file history can be quite different.
git log --follow -- file
and
On Mon, 2014-01-27 at 08:33 +0700, Duy Nguyen wrote:
On Mon, Jan 27, 2014 at 4:10 AM, Joe Perches j...@perches.com wrote:
For instance (using the Linus' linux kernel git):
$ time git log --follow -- drivers/firmware/google/Kconfig /dev/null
real0m42.329s
user0m40.984s
sys
If a file is deleted with git rm and a patch
is then generated with git format-patch -M -
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
(Sorry about the partial message.
evolution and ctrl-enter sends, grumble...)
If a file is deleted with git rm and a patch
is then generated with git format-patch -M -D
git am is unable to apply the resultant patch.
Is this working as designed?
--
To unsubscribe from this list: send the line
On Tue, 2012-11-13 at 14:55 -0800, Junio C Hamano wrote:
Joe Perches j...@perches.com writes:
(Sorry about the partial message.
evolution and ctrl-enter sends, grumble...)
If a file is deleted with git rm and a patch
is then generated with git format-patch -M -D
git am is unable
On Tue, 2012-11-13 at 03:21 +0530, Ramkumar Ramachandra wrote:
Felipe Contreras wrote:
cc-cmd is only per-file, and many times receipients get lost without
seing the full patch series.
s/seing/seeing
[...]
Looks good otherwise.
s/receipients/recipients/ too
Practically this is ok
On Tue, 2012-11-13 at 00:03 +0100, Felipe Contreras wrote:
On Mon, Nov 12, 2012 at 11:52 PM, Joe Perches j...@perches.com wrote:
On Tue, 2012-11-13 at 03:21 +0530, Ramkumar Ramachandra wrote:
Felipe Contreras wrote:
cc-cmd is only per-file, and many times receipients get lost without
On Tue, 2012-11-13 at 00:37 +0100, Felipe Contreras wrote:
On Tue, Nov 13, 2012 at 12:13 AM, Joe Perches j...@perches.com wrote:
On Tue, 2012-11-13 at 00:03 +0100, Felipe Contreras wrote:
[]
For --to-cmd and --cc-cmd? So basically you check the dirname of the
argument passed?
yes
38 matches
Mail list logo