On Fri, Jun 24, 2016 at 03:41:47PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The difference in time between the two is measurable on my system, but
> > it's only a few milliseconds (for 4096 bytes). So maybe it's not worth
> > worrying about (though as a general technique, it does m
Jeff King writes:
> The difference in time between the two is measurable on my system, but
> it's only a few milliseconds (for 4096 bytes). So maybe it's not worth
> worrying about (though as a general technique, it does make me worry
> that it's easy to get wrong in a way that will fail racily).
On Fri, Jun 24, 2016 at 04:58:58PM -0400, Eric Sunshine wrote:
> On Fri, Jun 24, 2016 at 3:07 PM, Jeff King wrote:
> > On Fri, Jun 24, 2016 at 11:56:19AM -0700, Junio C Hamano wrote:
> >> Jeff King writes:
> >> > +tar_info () {
> >> > + "$TAR" tvf "$1" | awk '{print $3 " " $4}' | cut -d- -f1
>
On Fri, Jun 24, 2016 at 03:07:44PM -0400, Jeff King wrote:
> > "dd bs=1 count=4096" is hopefully more portable.
>
> Hmm. I always wonder whether dd is actually very portable, but we do use
> it already, at least.
>
> Perhaps the perl monstrosity in t9300 could be replaced with that, too.
Hrm. S
On Fri, Jun 24, 2016 at 3:07 PM, Jeff King wrote:
> On Fri, Jun 24, 2016 at 11:56:19AM -0700, Junio C Hamano wrote:
>> Jeff King writes:
>> > +tar_info () {
>> > + "$TAR" tvf "$1" | awk '{print $3 " " $4}' | cut -d- -f1
>> > +}
>
>> Seeing an awk piped into cut always makes me want to suggest a
Jeff King writes:
>> > +# When parsing, we'll pull out only the year from the date; that
>> > +# avoids any question of timezones impacting the result.
>>
>> ... as long as the month-day part is not close to the year boundary.
>> So this explanation is insuffucient to convince the reader that
>
On Fri, Jun 24, 2016 at 11:56:19AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > The ustar format only has room for 11 (or 12, depending on
> > some implementations) octal digits for the size and mtime of
> > each file. After this, we have to add pax extended headers
> > to specify the
Jeff King writes:
> The ustar format only has room for 11 (or 12, depending on
> some implementations) octal digits for the size and mtime of
> each file. After this, we have to add pax extended headers
> to specify the real data, and git does not yet know how to
> do so.
I am not a native speak
Am 24.06.2016 um 18:46 schrieb Jeff King:
On Fri, Jun 24, 2016 at 06:38:55PM +0200, Johannes Sixt wrote:
It's going to be 269 with ksh, and who-knows-what on Windows (due to lack of
SIGPIPE - I haven't tested this, yet).
Thanks, I meant to ask about that. We do a workaround in t0005, but we
_d
On Fri, Jun 24, 2016 at 06:38:55PM +0200, Johannes Sixt wrote:
> Am 24.06.2016 um 01:20 schrieb Jeff King:
> > +# We expect git to die with SIGPIPE here (otherwise we
> > +# would generate the whole 64GB).
> > +test_expect_failure BUNZIP 'generate tar with huge size' '
> > + {
> > + gi
Am 24.06.2016 um 01:20 schrieb Jeff King:
+# We expect git to die with SIGPIPE here (otherwise we
+# would generate the whole 64GB).
+test_expect_failure BUNZIP 'generate tar with huge size' '
+ {
+ git archive HEAD
+ echo $? >exit-code
+ } | head -c 4096 >
On Thu, Jun 23, 2016 at 07:20:44PM -0400, Jeff King wrote:
> I'm still not excited about the 64MB write, just because it's awfully
> heavyweight for such a trivial test. It runs pretty fast on my RAM disk,
> but maybe not on other people's system.
>
> I considered but didn't explore two other opt
The ustar format only has room for 11 (or 12, depending on
some implementations) octal digits for the size and mtime of
each file. After this, we have to add pax extended headers
to specify the real data, and git does not yet know how to
do so.
Before fixing that, let's start off with some test
in
13 matches
Mail list logo
