Paul Mackerras wrote:
How about changing lines matching:?
Sorry for the slow response. Sounds perfect.
Thanks,
Jonathan
--
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
On Mon, May 13, 2013 at 2:55 PM, Jonathan Nieder jrnie...@gmail.com wrote:
My experience is the opposite. I wonder What did the author of this
nonsense comment mean? or What is the purpose of this strange
condition in this if () statement?. Then git log -S finds the
culprit
Only if that if
Martin Langhoff wrote:
On Mon, May 13, 2013 at 2:55 PM, Jonathan Nieder jrnie...@gmail.com wrote:
My experience is the opposite. I wonder What did the author of this
nonsense comment mean? or What is the purpose of this strange
condition in this if () statement?. Then git log -S finds the
On Mon, May 13, 2013 at 3:33 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Well, no, it should find the final change that brought it into the
current form. Just like git blame.
Has it been finding zero results in some cases where the current code
matches the pattern? That sounds like a bug.
Jonathan Nieder wrote:
Martin Langhoff wrote:
On Mon, May 13, 2013 at 2:55 PM, Jonathan Nieder jrnie...@gmail.com wrote:
My experience is the opposite. I wonder What did the author of this
nonsense comment mean? or What is the purpose of this strange
condition in this if () statement?.
Ramkumar Ramachandra wrote:
I still don't know exactly what -G and -S do.
If you've been following recent gitk development (or this thread)
closely, you'll know that git log -S finds commits adding/removing a
string, while git log -G finds commits changing lines matching a
regex.
Examples for
Martin Langhoff martin.langh...@gmail.com writes:
On Mon, May 13, 2013 at 3:33 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Well, no, it should find the final change that brought it into the
current form. Just like git blame.
Has it been finding zero results in some cases where the current
Paul Mackerras wrote:
I thought I had replied to this patch; maybe I only thought about it.
Given that we already have a selector to choose between exact and
regexp matching, it seems more natural to use that rather than add a
new selector entry. Arguably the IgnCase option should be
On Fri, May 10, 2013 at 11:13:22PM -0700, Jonathan Nieder wrote:
Paul Mackerras wrote:
I thought I had replied to this patch; maybe I only thought about it.
Given that we already have a selector to choose between exact and
regexp matching, it seems more natural to use that rather than
On Tue, May 07, 2013 at 01:17:18PM -0400, Martin Langhoff wrote:
I just did git rebase origin/master for the umpteenth time, which
reminded me this nice patch is still pending.
ping?
I thought I had replied to this patch; maybe I only thought about it.
Given that we already have a selector
I just did git rebase origin/master for the umpteenth time, which
reminded me this nice patch is still pending.
ping?
m
On Thu, Jun 14, 2012 at 2:34 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
From: Martin Langhoff mar...@laptop.org
git log -G'regex' is a very usable
On Tue, May 7, 2013 at 12:17 PM, Martin Langhoff
martin.langh...@gmail.com wrote:
I just did git rebase origin/master for the umpteenth time, which
reminded me this nice patch is still pending.
ping?
For some reason getting patches into gitk takes a long long looong time.
--
Felipe
12 matches
Mail list logo
