On Tue, Feb 23, 2016 at 03:01:43PM -0800, Junio C Hamano wrote:
> John Keeping writes:
>
> > My original sed version was:
> >
> > sed -ne "/^author /p" -e "/^summary /p"
> >
> > which I think will work on all platforms (we already use it in
> > t-basic.sh) but then I decided to be too cle
John Keeping writes:
> My original sed version was:
>
> sed -ne "/^author /p" -e "/^summary /p"
>
> which I think will work on all platforms (we already use it in
> t-basic.sh) but then I decided to be too clever :-(
>
> I still think sed is simpler than introducing a new function to wr
Jeff King writes:
> On Sun, Feb 21, 2016 at 11:41:35PM +, John Keeping wrote:
>
>> My original sed version was:
>>
>> sed -ne "/^author /p" -e "/^summary /p"
>>
>> which I think will work on all platforms (we already use it in
>> t-basic.sh) but then I decided to be too clever :-(
On Sun, Feb 21, 2016 at 11:41:35PM +, John Keeping wrote:
> My original sed version was:
>
> sed -ne "/^author /p" -e "/^summary /p"
>
> which I think will work on all platforms (we already use it in
> t-basic.sh) but then I decided to be too clever :-(
>
> I still think sed is si
On Sun, Feb 21, 2016 at 6:41 PM, John Keeping wrote:
> On Sun, Feb 21, 2016 at 06:19:14PM -0500, Jeff King wrote:
>> On Sun, Feb 21, 2016 at 04:01:27PM -0500, Eric Sunshine wrote:
>> > These tests all crash and burn with BSD sed (including Mac OS X) since
>> > you're not restricting yourself to BR
On Sun, Feb 21, 2016 at 06:19:14PM -0500, Jeff King wrote:
> On Sun, Feb 21, 2016 at 04:01:27PM -0500, Eric Sunshine wrote:
>
> > On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote:
> > > GNU grep 2.23 detects the input used in this test as binary data so it
> > > does not work for extracting l
On Sun, Feb 21, 2016 at 6:31 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> These tests all crash and burn with BSD sed (including Mac OS X) since
>> you're not restricting yourself to BRE (basic regular expressions).
>> You _could_ request extended regular expressions, which do work on
>
On Sun, Feb 21, 2016 at 06:31:08PM -0500, Eric Sunshine wrote:
> > Something like the patch below works for me. I think we could make it
> > shorter by using $PERLIO to get the raw behavior, but using binmode will
> > work even on ancient versions of perl.
> >
> > +filter_blame () {
> > + pe
On Sun, Feb 21, 2016 at 6:19 PM, Jeff King wrote:
> On Sun, Feb 21, 2016 at 04:01:27PM -0500, Eric Sunshine wrote:
>> On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote:
>> > - git blame --incremental file | \
>> > - egrep "^(author|summary) " > actual &&
>> > + git bl
Eric Sunshine writes:
> These tests all crash and burn with BSD sed (including Mac OS X) since
> you're not restricting yourself to BRE (basic regular expressions).
> You _could_ request extended regular expressions, which do work on
> those platforms, as well as with GNU sed:
>
> sed -nEe "/
On Sun, Feb 21, 2016 at 04:01:27PM -0500, Eric Sunshine wrote:
> On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote:
> > GNU grep 2.23 detects the input used in this test as binary data so it
> > does not work for extracting lines from a file. We could add the "-a"
> > option to force grep to
On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote:
> GNU grep 2.23 detects the input used in this test as binary data so it
> does not work for extracting lines from a file. We could add the "-a"
> option to force grep to treat the input as text, but not all
> implementations support that. In
GNU grep 2.23 detects the input used in this test as binary data so it
does not work for extracting lines from a file. We could add the "-a"
option to force grep to treat the input as text, but not all
implementations support that. Instead, use sed to extract the desired
lines since it will alway
13 matches
Mail list logo
