* Re: [PATCH v3 2/3] git-push: clean up some of the output from git push --porcelain
From: Larry D'Anna @ 2010-02-10 5:55 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20100210053937.GF28526@coredump.intra.peff.net>
* Jeff King (peff@peff.net) [100210 00:41]:
> I have not actually been running these patches, just reading them, but
> my impression was the goal _was_ to squelch all of the stderr cruft. But
> if we are not even close, then probably we should just give up and
> callers should "2>/dev/null".
Personally, I don't really care about squelching stderr cruft. All I really
want is for what goes to stdout be sane and the calling script to be able to
unambiguously figure out what happened, including
* which refs go to which remotes
* whether or not some mysterious error occurred (beyond those mentioned in the
ref status lines)
> I had initially endorsed it, but now I am having second thoughts.
> Especially if the "usual" calling convention is to redirect stderr as
> above, then we are probably missing out on any useful error messages
> that accompany a failure return, anyway. So maybe the sane thing to do
> is to leave the exit code alone, and include a --porcelain output line
> that either says "Everything was OK, see individual ref status" or "We
> couldn't even talk to the other side". Then the status code is
> irrelevant, and stdout contains all of the useful information (and if
> you don't get an error or OK message, you know there was some
> serious error like a broken git installation).
That serves my purposes as well as the exit code would. Is this the consensus?
--larry
^ permalink raw reply
* Re: git add -u nonexistent-file
From: Jeff King @ 2010-02-10 5:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Packham, SZEDER Gábor, git
In-Reply-To: <7v7hqm2hs7.fsf@alter.siamese.dyndns.org>
On Tue, Feb 09, 2010 at 01:58:16PM -0800, Junio C Hamano wrote:
> > That being said, you noticed that the regular add case notes unused
> > pathspecs on the command line:
> >
> > $ git add bogus
> > fatal: pathspec 'bogus' did not match any files
> >
> > We could probably do the same here.
>
> It won't be entirely trivial to do so efficiently but it shouldn't be a
> rocket surgery.
>
> Something like this (untested of course)?
Looks like Chris gave it some basic testing. I read over the patch
itself, and it looks sane to me.
-Peff
^ permalink raw reply
* A question about the tree associated with a git notes commit
From: Jon Seymour @ 2010-02-10 6:16 UTC (permalink / raw)
To: Jeff King; +Cc: Johan Herland, git
Is the tree associated with a notes commit limited to a single level,
or is there some attempt to balance the tree as the number of
annotated objects increases?
If the tree is currently restricted to a single level, is this
eventually going to be a problem as the number of annotated objects
continues to grow?
Apologies if this question is answered with trivial analysis of the
code, I admittedly haven't done that.
jon.
^ permalink raw reply
* Re: A question about the tree associated with a git notes commit
From: Junio C Hamano @ 2010-02-10 7:01 UTC (permalink / raw)
To: Jon Seymour; +Cc: Jeff King, Johan Herland, git
In-Reply-To: <2cfc40321002092216p5cbf432bs3766d40858f9bf3a@mail.gmail.com>
Jon Seymour <jon.seymour@gmail.com> writes:
> Apologies if this question is answered with trivial analysis of the
> code, I admittedly haven't done that.
Output from "git log master..0ce25c4b" and especially and c07d5eb (t3305:
Verify that adding many notes with git-notes triggers increased fanout,
2010-01-27) and 71942f4 (t3305: Verify that removing notes triggers
automatic fanout consolidation, 2010-01-27) would be of interest.
^ permalink raw reply
* Re: [PATCH 8/6] receive-pack: Send internal errors over side-band #2
From: Johannes Sixt @ 2010-02-10 7:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1265767290-25863-2-git-send-email-spearce@spearce.org>
Shawn O. Pearce schrieb:
> +static void rp_error(const char *err, ...) __attribute__((format (printf, 1, 2)));
> +static void rp_warning(const char *err, ...) __attribute__((format (printf, 1, 2)));
> +
> +static void report_message(const char *prefix, const char *err, va_list params)
> +{
> + int sz = strlen(prefix);
> + char msg[4096];
> +
> + strncpy(msg, prefix, sz);
> + sz += vsnprintf(msg + sz, sizeof(msg) - (sz + 1), err, params);
> + msg[sz++] = '\n';
This writes beyond the buffer if it is too small because the return value
tells how many characters *would* have been written if it were
sufficiently large, no?
> +
> + if (use_sideband)
> + send_sideband(1, 2, msg, sz, use_sideband);
> + else
> + xwrite(2, msg, sz);
> +}
> +
> +static void rp_warning(const char *err, ...)
> ...
> +static void rp_error(const char *err, ...)
> ...
Looks like we need set_report_routine().
Or did you replace only selected error() and warning() calls by rp_error()
and rp_warning()?
-- Hannes
^ permalink raw reply
* Re: [PATCH 8/6] receive-pack: Send internal errors over side-band #2
From: Junio C Hamano @ 2010-02-10 7:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, git
In-Reply-To: <4B725CB1.1080908@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Looks like we need set_report_routine().
>
> Or did you replace only selected error() and warning() calls by rp_error()
> and rp_warning()?
That actually sounds like a good suggestion.
^ permalink raw reply
* [PATCH] blame: allow -L n,m to have an m bigger than the file's line count
From: Stephen Boyd @ 2010-02-10 7:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jay Soffian
Sometimes I want to blame a file starting at some point and ending at
the end of the file. In my haste I'll write something like this:
$ git blame -L5,2342343 -- builtin-blame.c
and be greeted by a die message telling me that my end range is greater
than the number of lines in the file. Obviously I can do:
$ git blame -L5, -- builtin-blame.c
and get what I want but that isn't very discoverable. If the range is
greater than the number of lines just truncate the range to go up to
the end of the file.
Update the docs to more accurately reflect the defaults for n and m too.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
I realize this is late in the game for 1.7.0 so I'll resend if this
isn't picked up.
Documentation/blame-options.txt | 4 +++-
builtin-blame.c | 4 +++-
t/t8003-blame.sh | 4 ++--
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 4833cac..620660d 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -9,7 +9,7 @@
--show-stats::
Include additional statistics at the end of blame output.
--L <start>,<end>::
+-L [<start>],[<end>]::
Annotate only the given line range. <start> and <end> can take
one of these forms:
@@ -31,6 +31,8 @@ starting at the line given by <start>.
This is only valid for <end> and will specify a number
of lines before or after the line given by <start>.
+
+Note: if <start> is not given it defaults to 1 and if <end> is not given it
+defaults to the number of lines in the file.
-l::
Show long rev (Default: off).
diff --git a/builtin-blame.c b/builtin-blame.c
index 10f7eac..77b7323 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1962,6 +1962,8 @@ static void prepare_blame_range(struct scoreboard *sb,
term = parse_loc(term + 1, sb, lno, *bottom + 1, top);
if (*term)
usage(blame_usage);
+ if (lno < *top)
+ *top = lno;
}
if (*term)
usage(blame_usage);
@@ -2238,7 +2240,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
OPT_STRING(0, "contents", &contents_from, "file", "Use <file>'s contents as the final image"),
{ OPTION_CALLBACK, 'C', NULL, &opt, "score", "Find line copies within and across files", PARSE_OPT_OPTARG, blame_copy_callback },
{ OPTION_CALLBACK, 'M', NULL, &opt, "score", "Find line movements within and across files", PARSE_OPT_OPTARG, blame_move_callback },
- OPT_CALLBACK('L', NULL, &bottomtop, "n,m", "Process only line range n,m, counting from 1", blame_bottomtop_callback),
+ OPT_CALLBACK('L', NULL, &bottomtop, "[n],[m]", "Process only line range n,m, counting from 1", blame_bottomtop_callback),
OPT_END()
};
diff --git a/t/t8003-blame.sh b/t/t8003-blame.sh
index 4a8db74..0ba150e 100755
--- a/t/t8003-blame.sh
+++ b/t/t8003-blame.sh
@@ -161,8 +161,8 @@ test_expect_success 'blame -L with invalid start' '
test_must_fail git blame -L5 tres 2>&1 | grep "has only 2 lines"
'
-test_expect_success 'blame -L with invalid end' '
- git blame -L1,5 tres 2>&1 | grep "has only 2 lines"
+test_expect_success 'blame -L with invalid end truncates automatically' '
+ git blame -L1,5 tres
'
test_done
--
1.7.0.rc2.13.g8b233
^ permalink raw reply related
* Re: [PATCH 8/6] receive-pack: Send internal errors over side-band #2
From: Johannes Sixt @ 2010-02-10 8:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <4B725CB1.1080908@viscovery.net>
Johannes Sixt schrieb:
> Or did you replace only selected error() and warning() calls by rp_error()
> and rp_warning()?
Actually, you want to send only selected messages to the pusher. For
example, these look like errors on the server side (right?) and should go
to the site administrator:
> if (!is_null_sha1(new_sha1) && !has_sha1_file(new_sha1)) {
> - error("unpack should have generated %s, "
> - "but I can't find it!", sha1_to_hex(new_sha1));
> + rp_error("unpack should have generated %s, "
> + "but I can't find it!", sha1_to_hex(new_sha1));
> return "bad pack";
> }
> if (!old_object || !new_object ||
> old_object->type != OBJ_COMMIT ||
> new_object->type != OBJ_COMMIT) {
> - error("bad sha1 objects for %s", name);
> + rp_error("bad sha1 objects for %s", name);
> return "bad ref";
> }
> old_commit = (struct commit *)old_object;
In particular, your patch does not send errors produced by unpack-objects
or index-pack to the pusher over the sideband, and this is the right thing
to do.
-- Hannes
^ permalink raw reply
* Re: A question about the tree associated with a git notes commit
From: Jon Seymour @ 2010-02-10 8:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Johan Herland, git
In-Reply-To: <7vmxzhfuat.fsf@alter.siamese.dyndns.org>
Thanks..apologies for not seeking the answer myself.
jon.
On Wed, Feb 10, 2010 at 6:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> Apologies if this question is answered with trivial analysis of the
>> code, I admittedly haven't done that.
>
> Output from "git log master..0ce25c4b" and especially and c07d5eb (t3305:
> Verify that adding many notes with git-notes triggers increased fanout,
> 2010-01-27) and 71942f4 (t3305: Verify that removing notes triggers
> automatic fanout consolidation, 2010-01-27) would be of interest.
>
^ permalink raw reply
* Re: RFC: git sync
From: Jakub Narebski @ 2010-02-10 9:52 UTC (permalink / raw)
To: Larry D'Anna; +Cc: git
In-Reply-To: <20100210032720.GA5205@cthulhu>
Larry D'Anna <larry@elder-gods.org> writes:
> So say you have a project with a bunch of branches. You have two main computers
> you work on: a laptop and a workstation, and you keep an authoritative copy on a
> server somewhere. When you sit down at your laptop to work on your project, the
> first thing you want to do is make sure that whatever you've got locally is
> up-to-date with the repo on the server. So you run:
>
> git push origin :
>
> Then if it says anything isn't a fast-forward, you use some combination of git
> pull, git checkout, or git fetch to get all you branches up to date, then
> possibly you run the push again to push merges back to the server.
>
> How about instead we add a new command called "git sync" that does all that for
> you? So if you say
>
> git sync origin :
[...]
> What do you all think? If you like the idea, I'll do it as a builtin.
> Otherwise I'll just hack up a perl script for myself.
Why not use the recpie from GitFaq:
"How would I use "git push" to sync out of a host that I cannot pull from?"
http://git.wiki.kernel.org/index.php/GitFaq#How_would_I_use_.22git_push.22_to_sync_out_of_a_host_that_I_cannot_pull_from.3F
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [Announce] bup 0.09: git-based backup system for really huge datasets
From: Jakub Narebski @ 2010-02-10 9:54 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Git Mailing List
In-Reply-To: <32541b131002091448o6f809322x1d86d2d7f74a80ed@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
> bup is a file backup tool based on the git packfile format.
[...]
> bup is still pretty experimental, but it's already a useful tool for
> backing up your files, even if those files include millions of files
> and hundreds of gigs of VM images.
>
> You can find the source code (and README) at github:
>
> http://github.com/apenwarr/bup
>
> To subscribe to the bup mailing list, send an email to:
>
> bup-list+subscribe@googlegroups.com
>
> Looking forward to everyone's feedback.
Would you be adding short info about your project to
http://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH v3 2/3] git-push: clean up some of the output from git push --porcelain
From: Tay Ray Chuan @ 2010-02-10 10:43 UTC (permalink / raw)
To: Larry D'Anna; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <20100210055529.GA1566@cthulhu>
Hi,
On Wed, Feb 10, 2010 at 1:55 PM, Larry D'Anna <larry@elder-gods.org> wrote:
> * Jeff King (peff@peff.net) [100210 00:41]:
>> I had initially endorsed it, but now I am having second thoughts.
>> Especially if the "usual" calling convention is to redirect stderr as
>> above, then we are probably missing out on any useful error messages
>> that accompany a failure return, anyway. So maybe the sane thing to do
>> is to leave the exit code alone, and include a --porcelain output line
>> that either says "Everything was OK, see individual ref status" or "We
>> couldn't even talk to the other side". Then the status code is
>> irrelevant, and stdout contains all of the useful information (and if
>> you don't get an error or OK message, you know there was some
>> serious error like a broken git installation).
>
> That serves my purposes as well as the exit code would. Is this the consensus?
does this mean the ugly return status mangling patch (git-push: make
git push --dry-run --porcelain exit with status 0 even if updates will
be rejected) would be dropped? If so, I'm all for it. =p
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Suggestion on git-push --porcelain
From: Tay Ray Chuan @ 2010-02-10 11:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Larry D'Anna, Jeff King
In-Reply-To: <7vmxzhn6fp.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, Feb 10, 2010 at 10:57 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
>> $ git push --porcelain
>> PORCELAIN To git://foo.com/git/myrepo.git
>> PORCELAIN uptodate refs/heads/baz:refs/heads/baz 1234ab ba4321
>> PORCELAIN nonff refs/heads/bar:refs/heads/bar 2345cd 3456de
>>
>> This is an "positive" approach, in the sense that we don't remove
>> anything from the current output; we just add more printf("PORCELAIN")
>> lines to wherever is appropriate.
>
> Sorry, but I don't see what that would solve. For example, we used not to
> give the destination to the standard output stream, but that line carries
> a necessary information and Larry's series corrects that.
I sense a chicken-and-egg situation here.
Printing a "To: <destination>" to stdout is a correction as far as the
current non-prefixed output scheme is concerned.
If a prefixed scheme (or some other output scheme) is adopted, then
where, or whether, the "To: <destination>" is printed, is not relevant
to porcelain script writers - they just get ignored.
> In your "prefix with PORCELAIN" scheme, such a change will start adding a
> new line "PORCELAIN To ..." that older implementations may not be prepared
> to see.
The original --porcelain patch only "porcelained" the output for ref
updates, such as
= TAB refs/heads/master:refs/heads/master TAB [up to date]
- TAB :refs/heads/foobar TAB [deleted]
...
In addition, the "To: <destination>" patch --porcelain is fairly
recent - I don't think it has left 'pu', has it? Should we worry about
breaking compatibility on something not out yet?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Suggestion on git-push --porcelain
From: Tay Ray Chuan @ 2010-02-10 11:28 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git Mailing List, Larry D'Anna
In-Reply-To: <20100210045446.GC28526@coredump.intra.peff.net>
Hi,
On Wed, Feb 10, 2010 at 12:54 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Feb 09, 2010 at 06:57:46PM -0800, Junio C Hamano wrote:
>
>> Tay Ray Chuan <rctay89@gmail.com> writes:
>>
>> > $ git push --porcelain
>> > PORCELAIN To git://foo.com/git/myrepo.git
>> > PORCELAIN uptodate refs/heads/baz:refs/heads/baz 1234ab ba4321
>> > PORCELAIN nonff refs/heads/bar:refs/heads/bar 2345cd 3456de
>> >
>> > This is an "positive" approach, in the sense that we don't remove
>> > anything from the current output; we just add more printf("PORCELAIN")
>> > lines to wherever is appropriate.
>>
>> Sorry, but I don't see what that would solve. For example, we used not to
>> give the destination to the standard output stream, but that line carries
>> a necessary information and Larry's series corrects that.
>
> I think he is trying to future-proof any additional output that push (or
> remote helpers) produce.
Yes. By using this (or some other output scheme), we're deliberately
marking out output for porcelain scripts.
> I don't think it is really worth it, though.
> All of that should be going to stderr, and thus would be, at worst,
> noise on the terminal. I don't think it is that hard or error-prone a
> rule to send such cruft to stderr.
on examining the code paths, there's a fair bit of work needed to
ensure this. Apart from transport.c (transport-helper.c and by
extension, remote helpers, looks ok), we would have to look at the
individual builtin-transport implementations for git and bundle.
Also, as you mentioned above, we would also have to take care future
transport implementations send messages in the desired fashion so that
we wouldn't break porcelain scripts. If we have an output scheme, then
such risks are minimized.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [RFC PATCHv2 04/10] gitweb: Use Cache::Cache compatibile (get, set) output caching
From: Jakub Narebski @ 2010-02-10 11:28 UTC (permalink / raw)
To: Petr Baudis
Cc: git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
In-Reply-To: <20100210012343.GS9553@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 4118 bytes --]
On Wed, 10 Feb 2010, Petr Baudis wrote:
> On Wed, Feb 10, 2010 at 02:12:24AM +0100, Jakub Narebski wrote:
> > On Tue, 9 Feb 2010 at 11:30 +0100, Jakub Narebski wrote:
> >
> > > The cache_fetch subroutine captures output (from STDOUT only, as
> > > STDERR is usually logged) using either ->push_layer()/->pop_layer()
> > > from PerlIO::Util submodule (if it is available), or by setting and
> > > restoring *STDOUT. Note that only the former could be tested reliably
> > > to be reliable in t9503 test!
> >
> > Scratch that, I have just checked that (at least for Apache + mod_cgi,
> > but I don't think that it matters) the latter solution, with setting
> > and restoring *STDOUT doesn't work: I would get data in cache (so it
> > can be restored later), but instead of output I would get Internal Server
> > Error ("The server encountered an internal error or misconfiguration and
> > was unable to complete your request.") without even a hint what the
> > problem was. Sprinkling "die ...: $!" didn't help to catch this error:
> > I suspect that the problem is with capturing.
> >
> > So we either would have to live with non-core PerlIO::Util or (pure Perl)
> > Capture::Tiny, or do the 'print -> print $out' patch...
>
> All the magic methods seem to be troublesome, but in that case I'd
> really prefer a level of indirection instead of filehandle - as is,
> 'print (...) -> output (...)' ins. of 'print (...) -> print $out (...)'
> (or whatever). That should be really flexible and completely
> futureproof, and I don't think the level of indirection would incur any
> measurable overhead, would it?
First, it is not only 'print (...) -> print $out (...)'; you need to
do all those:
print <sth> -> print $out <sth>
printf <sth> -> printf $out <sth>
binmode STDOUT, <mode> -> binmode $out, <mode>
Second, using "tie" on filehandle (on *STDOUT) can be used also for
just capturing output, not only for "tee"-ing; what's more to print
while capturing one has to do extra work. It is quite similar to
replacing 'print (...)' with 'output (...)' etc., but using
tie/untie doesn't require large patch to gitweb.
Third, as you can see below tie-ing is about 1% slower than using
'output (...)', which in turn is less than 10% slower than explicit
filehandle solution i.e. 'print $out (...)'... and is almost twice
slower than solution using PerlIO::Util
Benchmark: timing 50000 iterations of output, perlio, print \$out, tie *STDOUT...
output: 1.81462 wallclock secs ( 1.77 usr + 0.00 sys = 1.77 CPU) @ 28248.59/s (n=50000)
perlio: 1.05585 wallclock secs ( 1.03 usr + 0.00 sys = 1.03 CPU) @ 48543.69/s (n=50000)
print \$out: 1.70027 wallclock secs ( 1.66 usr + 0.00 sys = 1.66 CPU) @ 30120.48/s (n=50000)
tie *STDOUT: 1.82248 wallclock secs ( 1.79 usr + 0.00 sys = 1.79 CPU) @ 27932.96/s (n=50000)
Rate tie *STDOUT output print \$out perlio
tie *STDOUT 27933/s -- -1% -7% -42%
output 28249/s 1% -- -6% -42%
print \$out 30120/s 8% 7% -- -38%
perlio 48544/s 74% 72% 61% --
Benchmark: running output, perlio, print \$out, tie *STDOUT for at least 10 CPU seconds...
output: 10.7199 wallclock secs (10.53 usr + 0.00 sys = 10.53 CPU) @ 28029.63/s (n=295152)
perlio: 11.2884 wallclock secs (10.46 usr + 0.00 sys = 10.46 CPU) @ 49967.11/s (n=522656)
print \$out: 10.5978 wallclock secs (10.43 usr + 0.00 sys = 10.43 CPU) @ 30318.79/s (n=316225)
tie *STDOUT: 11.3525 wallclock secs (10.68 usr + 0.00 sys = 10.68 CPU) @ 27635.96/s (n=295152)
Rate tie *STDOUT output print \$out perlio
tie *STDOUT 27636/s -- -1% -9% -45%
output 28030/s 1% -- -8% -44%
print \$out 30319/s 10% 8% -- -39%
perlio 49967/s 81% 78% 65% --
need
Attached there is script that was used to produce those results.
--
Jakub Narebski
Poland
[-- Attachment #2: Benchmark of different ways of capturing output in Perl code --]
[-- Type: text/plain, Size: 3491 bytes --]
#!/usr/bin/perl
use strict;
use warnings;
use Test::More;
use Time::HiRes;
use Benchmark qw(:all :hireswallclock);
use Data::Dumper;
use PerlIO::Util;
my $chunk = "test\n";
my $lorem = <<'EOF';
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco laboris nisi ut
aliquip ex ea commodo consequat. Duis aute irure dolor in
reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
Sed ut perspiciatis unde omnis iste natus error sit voluptatem
accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae
ab illo inventore veritatis et quasi architecto beatae vitae dicta
sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit
aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos
qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui
dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed
quia non numquam eius modi tempora incidunt ut labore et dolore magnam
aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum
exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex
ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in
ea voluptate velit esse quam nihil molestiae consequatur, vel illum
qui dolorem eum fugiat quo voluptas nulla pariatur?
EOF
sub capture_perlio {
my $data = '';
*STDOUT->push_layer(scalar => \$data);
print $chunk;
*STDOUT->pop_layer();
return $data;
}
my $out = \*STDOUT;
sub capture_filehandle {
my $data = '';
open my $data_fh, '>', \$data;
$out = $data_fh;
print $out $chunk;
$out = \*STDOUT;
close $data_fh;
return $data;
}
sub output {
print $out @_;
}
sub capture_indirection {
my $data = '';
open my $data_fh, '>', \$data;
$out = $data_fh;
output $chunk;
$out = \*STDOUT;
close $data_fh;
return $data;
}
sub capture_tied {
my $data = '';
tie *STDOUT, 'CatchSTDOUT', \$data;
print $chunk;
untie *STDOUT;
return $data;
}
{
package CatchSTDOUT;
use strict;
use warnings;
use Data::Dumper;
sub TIEHANDLE {
my ($proto, $dataref) = @_;
my $class = ref($proto) || $proto;
my $self = {};
$self = bless($self, $class);
$self->{'scalar'} = $dataref;
return $self;
}
sub PRINT {
my $self = shift;
${$self->{'scalar'}} .= join('',@_);
}
}
# ----------------------------------------------------------------------
print 'capture_perlio = '.capture_perlio();
print 'capture_filehandle = '.capture_filehandle();
print 'capture_indirection = '.capture_indirection();
print 'capture_tied = '.capture_tied();
$chunk = "another test\n";
print 'capture_perlio = '.capture_perlio();
print 'capture_filehandle = '.capture_filehandle();
print 'capture_indirection = '.capture_indirection();
print 'capture_tied = '.capture_tied();
print "\n";
$chunk = $lorem;
my $result = timethese(50_000, {
'perlio' => \&capture_perlio,
'print \$out' => \&capture_filehandle,
'output' => \&capture_indirection,
'tie *STDOUT' => \&capture_indirection,
});
cmpthese($result);
print "\n";
$result = timethese(-10, {
'perlio' => \&capture_perlio,
'print \$out' => \&capture_filehandle,
'output' => \&capture_indirection,
'tie *STDOUT' => \&capture_indirection,
});
cmpthese($result);
print "\n";
^ permalink raw reply
* Re: [RFC PATCHv2 04/10] gitweb: Use Cache::Cache compatibile (get, set) output caching
From: Petr Baudis @ 2010-02-10 12:02 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
In-Reply-To: <201002101228.15732.jnareb@gmail.com>
On Wed, Feb 10, 2010 at 12:28:14PM +0100, Jakub Narebski wrote:
> On Wed, 10 Feb 2010, Petr Baudis wrote:
> > On Wed, Feb 10, 2010 at 02:12:24AM +0100, Jakub Narebski wrote:
> > > On Tue, 9 Feb 2010 at 11:30 +0100, Jakub Narebski wrote:
> > >
> > > > The cache_fetch subroutine captures output (from STDOUT only, as
> > > > STDERR is usually logged) using either ->push_layer()/->pop_layer()
> > > > from PerlIO::Util submodule (if it is available), or by setting and
> > > > restoring *STDOUT. Note that only the former could be tested reliably
> > > > to be reliable in t9503 test!
> > >
> > > Scratch that, I have just checked that (at least for Apache + mod_cgi,
> > > but I don't think that it matters) the latter solution, with setting
> > > and restoring *STDOUT doesn't work: I would get data in cache (so it
> > > can be restored later), but instead of output I would get Internal Server
> > > Error ("The server encountered an internal error or misconfiguration and
> > > was unable to complete your request.") without even a hint what the
> > > problem was. Sprinkling "die ...: $!" didn't help to catch this error:
> > > I suspect that the problem is with capturing.
> > >
> > > So we either would have to live with non-core PerlIO::Util or (pure Perl)
> > > Capture::Tiny, or do the 'print -> print $out' patch...
> >
> > All the magic methods seem to be troublesome, but in that case I'd
> > really prefer a level of indirection instead of filehandle - as is,
> > 'print (...) -> output (...)' ins. of 'print (...) -> print $out (...)'
> > (or whatever). That should be really flexible and completely
> > futureproof, and I don't think the level of indirection would incur any
> > measurable overhead, would it?
>
> First, it is not only 'print (...) -> print $out (...)'; you need to
> do all those:
>
> print <sth> -> print $out <sth>
> printf <sth> -> printf $out <sth>
> binmode STDOUT, <mode> -> binmode $out, <mode>
>
> Second, using "tie" on filehandle (on *STDOUT) can be used also for
> just capturing output, not only for "tee"-ing; what's more to print
> while capturing one has to do extra work. It is quite similar to
> replacing 'print (...)' with 'output (...)' etc., but using
> tie/untie doesn't require large patch to gitweb.
>
> Third, as you can see below tie-ing is about 1% slower than using
> 'output (...)', which in turn is less than 10% slower than explicit
> filehandle solution i.e. 'print $out (...)'... and is almost twice
> slower than solution using PerlIO::Util
>
> Benchmark: timing 50000 iterations of output, perlio, print \$out, tie *STDOUT...
> output: 1.81462 wallclock secs ( 1.77 usr + 0.00 sys = 1.77 CPU) @ 28248.59/s (n=50000)
> perlio: 1.05585 wallclock secs ( 1.03 usr + 0.00 sys = 1.03 CPU) @ 48543.69/s (n=50000)
> print \$out: 1.70027 wallclock secs ( 1.66 usr + 0.00 sys = 1.66 CPU) @ 30120.48/s (n=50000)
> tie *STDOUT: 1.82248 wallclock secs ( 1.79 usr + 0.00 sys = 1.79 CPU) @ 27932.96/s (n=50000)
> Rate tie *STDOUT output print \$out perlio
> tie *STDOUT 27933/s -- -1% -7% -42%
> output 28249/s 1% -- -6% -42%
> print \$out 30120/s 8% 7% -- -38%
> perlio 48544/s 74% 72% 61% --
>
> Benchmark: running output, perlio, print \$out, tie *STDOUT for at least 10 CPU seconds...
> output: 10.7199 wallclock secs (10.53 usr + 0.00 sys = 10.53 CPU) @ 28029.63/s (n=295152)
> perlio: 11.2884 wallclock secs (10.46 usr + 0.00 sys = 10.46 CPU) @ 49967.11/s (n=522656)
> print \$out: 10.5978 wallclock secs (10.43 usr + 0.00 sys = 10.43 CPU) @ 30318.79/s (n=316225)
> tie *STDOUT: 11.3525 wallclock secs (10.68 usr + 0.00 sys = 10.68 CPU) @ 27635.96/s (n=295152)
> Rate tie *STDOUT output print \$out perlio
> tie *STDOUT 27636/s -- -1% -9% -45%
> output 28030/s 1% -- -8% -44%
> print \$out 30319/s 10% 8% -- -39%
> perlio 49967/s 81% 78% 65% --
> need
>
> Attached there is script that was used to produce those results.
Ok, on my machine it's similar:
Rate output tie *STDOUT print \$out
output 150962/s -- -1% -7%
tie *STDOUT 152769/s 1% -- -6%
print \$out 162604/s 8% 6% --
is roughly consistent image coming out of it.
I guess the time spent here is generally negligible in gitweb anyway...
I suggested using output() because I think hacking it would be _very_
_slightly_ easier than tied filehandle, but you are right that doing
that is also really easy; having the possibility to use PerlIO::Util if
available would be non-essentially nice, but requiring it by stock
gitweb is not reasonable, especially seeing that it's not packaged even
for Debian. ;-)
--
Petr "Pasky" Baudis
If you can't see the value in jet powered ants you should turn in
your nerd card. -- Dunbal (464142)
^ permalink raw reply
* git-svn taking a long time
From: David Kågedal @ 2010-02-10 12:41 UTC (permalink / raw)
To: Git Mailing List
I compiled the perl bindings from subversion 1.6.x, and git git version
1.7.0.rc0.52.g64ba.
I have imported a largish svn repo using "git svn fetch", which takes
quite a long time (at least a day).
But my problems is that if I rerun "git svn fetch" again right after
fetching, it will chew for hours before figuring out there are just a
few new revisions to import. And the same if I try again.
I have another import from the same repo (on another machine, using
slightly different versions of stuff) that doesn't have this problem.
So, does anyone have any suggestions for what could be done about this?
This is what the entry i .git/config looks like (url edited to protect
the innocent)
[svn-remote "svn"]
url = svn://svn.server
branches = foo/branches/*:refs/remotes/svn/*
tags = foo/tags/*:refs/remotes/svn/tags/*
--
David Kågedal
^ permalink raw reply
* Re: [PATCH] blame: allow -L n,m to have an m bigger than the file's line count
From: SZEDER Gábor @ 2010-02-10 12:42 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano, Jay Soffian
In-Reply-To: <1265786864-5460-1-git-send-email-bebarino@gmail.com>
Hi Stephen,
On Tue, Feb 09, 2010 at 11:27:44PM -0800, Stephen Boyd wrote:
> Sometimes I want to blame a file starting at some point and ending at
> the end of the file. In my haste I'll write something like this:
>
> $ git blame -L5,2342343 -- builtin-blame.c
>
> and be greeted by a die message telling me that my end range is greater
> than the number of lines in the file. Obviously I can do:
>
> $ git blame -L5, -- builtin-blame.c
>
> and get what I want but that isn't very discoverable. If the range is
> greater than the number of lines just truncate the range to go up to
> the end of the file.
>
> Update the docs to more accurately reflect the defaults for n and m too.
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
>
> I realize this is late in the game for 1.7.0 so I'll resend if this
> isn't picked up.
>
> Documentation/blame-options.txt | 4 +++-
> builtin-blame.c | 4 +++-
> t/t8003-blame.sh | 4 ++--
> 3 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
> index 4833cac..620660d 100644
> --- a/Documentation/blame-options.txt
> +++ b/Documentation/blame-options.txt
> @@ -9,7 +9,7 @@
> --show-stats::
> Include additional statistics at the end of blame output.
>
> --L <start>,<end>::
> +-L [<start>],[<end>]::
> Annotate only the given line range. <start> and <end> can take
> one of these forms:
>
> @@ -31,6 +31,8 @@ starting at the line given by <start>.
> This is only valid for <end> and will specify a number
> of lines before or after the line given by <start>.
> +
> +Note: if <start> is not given it defaults to 1 and if <end> is not given it
> +defaults to the number of lines in the file.
>
> -l::
> Show long rev (Default: off).
I agree that its too late for the behavioral change, but IMHO the
documentation update part can be considered as a bugfix, and as such
it could perhaps be included in 1.7.0. (I never knew that <start> or
<end> can be omitted... so thanks for the hint anyway)
Best,
Gábor
^ permalink raw reply
* Re: [PATCH 4/4] Add test for using Git at root of file system
From: João Carlos Mendes Luís @ 2010-02-10 13:10 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano, Johannes Sixt
In-Reply-To: <1265734950-15145-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy wrote:
> This kind of test requires a throw-away root filesystem so that it can
> play on. If you have such a system, go ahead, "chmod 777 /" and run
> this test manually ("make test" with root permission won't work).
>
I've seen you have a prepare-chroot.sh file in there. Is it working or
not? I mean, did you create a chrooted environment to test, or there
was any problem with that?
^ permalink raw reply
* Re: [PATCH] blame: allow -L n,m to have an m bigger than the file's line count
From: Jay Soffian @ 2010-02-10 13:37 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano
In-Reply-To: <1265786864-5460-1-git-send-email-bebarino@gmail.com>
On Wed, Feb 10, 2010 at 2:27 AM, Stephen Boyd <bebarino@gmail.com> wrote:
> and get what I want but that isn't very discoverable. If the range is
> greater than the number of lines just truncate the range to go up to
> the end of the file.
I agree this is the right thing to do. I'm working on a patch to
support matching multiple times when given a regex range and made just
that change as well. :-)
j.
^ permalink raw reply
* cherry-pick from a branch to another with git-svn automatically stripping git-svn-id from commit message
From: Daniele Segato @ 2010-02-10 15:44 UTC (permalink / raw)
To: git
Hi,
since git-svn modify the commit message when you dcommit something
(git svn dcommit)
and then use the commit message to decide which is the branch to
dcommit next cherry-pick-ing
(and other commands) has some problem when you work through different
svn branch.
Example, you have 2 remote branch: remote/trunk, remote/v1.x
and you are following them with two branches: trunk and v1.x
now say you want to cherry-pick a commit from trunk into v1.x locally
to dcommit it onto the remote/v1.x branch.
the step you had to do are:
git cherry-pick <your-commit-hash-on-trunk>
git commit --amend # removing the line starting with git-svn-id
# or add the -e option to cherry-pick instead of amending
git svn dcommit
now, if you have to do it frequently it is a bit annoying and you man
do some mistake.
I want to make it automatic and easy to use like:
git cherry-pick-svn <your-commit-hash-on-trunk>
git svn dcommit
with an alias.
on #irc charon suggested me to use !GIT_EDITOR="script that strip the
git-svn-id here" git cherry-pick ...
so I tried this from command line (hash is just a random one):
GIT_EDITOR="sed -i '/^git-svn-id:/d'" git cherry-pick -e 9eb6b7de
it works.
so I opened my ~/.gitconfig and added this alias:
[alias]
cherry-pick-svn = !GIT_EDITOR="sed -i '/^git-svn-id:/d'" git cherry-pick -e
but with
$ git cherry-pick-svn 9eb6b7de
I get:
sh: -i: command not found
fatal: Failed to run 'GIT_EDITOR=sed -i -e '/^git-svn-id:/d' git
cherry-pick -e '9eb6b7de...'' when expanding alias 'cherry-pick-svn'
but modifying it with this:
[alias]
cherry-pick-svn = !GIT_EDITOR='sed -i /^git-svn-id:/d' git cherry-pick -e
made it working.
I just want to share this with you if someone need it.
And may be ask if you find any problem with this or if you have a
better way to do it
Regards,
Daniele
^ permalink raw reply
* Re: [PATCH] Documentation: reword --thin description
From: Nicolas Pitre @ 2010-02-10 16:07 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Junio C Hamano
In-Reply-To: <1265778851-5397-1-git-send-email-bebarino@gmail.com>
On Tue, 9 Feb 2010, Stephen Boyd wrote:
> --thin::
> - Spend extra cycles to minimize the number of objects to be sent.
> - Use it on slower connection.
> + Spend extra cycles minimizing the number of sent objects.
> + Use it with a slow connection.
Both the old and the new text are bollocks.
There is no extra cycles involved here. And linking this to a slow
connection is misleading.
The point of --thin is to create a pack containing delta objects while
excluding the base objects they depend on when those objects are known
to exist in the receiver's repository already. Because base objects
are usually significantly bigger than delta objects, this results in a
large reduction in the amount of data to transfer.
However we don't allow a pack with delta objects referencing base
objects to be stored in a Git repository if those base objects are not
part of the same pack for robustness reasons. Therefore, when a thin
pack is transferred via the git protocol, the receiving end must
"fatten" the pack by appending those missing base objects for that pack
to be complete and valid. This results in somewhat suboptimal object
storage on the receiving end due to some object duplications. Of course
a simple gc will fix that.
These days --thin is always the default for a fetch. We used to think
that --thin might not be the best thing to do on a push given that the
receiving end is typically a central server in that case and keeping
storage low on a central server should be preferred. But --thin turned
out to be re-enabled by default for pushes by mistake on a few occasions
when the affected code has been reworked. No idea what state it is now,
and I don't think that makes such a difference on the server in the end.
Nicolas
^ permalink raw reply
* Re: [PATCH] blame: allow -L n,m to have an m bigger than the file's line count
From: Stephen Boyd @ 2010-02-10 16:25 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Junio C Hamano
In-Reply-To: <76718491002100537h521fcc26gb267ed7cd2b8db6f@mail.gmail.com>
On 02/10/2010 05:37 AM, Jay Soffian wrote:
> I agree this is the right thing to do. I'm working on a patch to
> support matching multiple times when given a regex range and made just
> that change as well. :-)
>
Great! I'll split the patch into a documentation patch (for 1.7.0) and a
behavioral patch (for post 1.7.0)? Or perhaps you can take care of the
behavioral change in your upcoming series?
^ permalink raw reply
* [PATCH] Documentation: quote braces in {upstream} notation
From: Thomas Rast @ 2010-02-10 16:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The lack of quoting made the entire line disappear.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-rev-parse.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index fc73152..d677c72 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -244,7 +244,7 @@ when you run 'git merge'.
* The special construct '@\{-<n>\}' means the <n>th branch checked out
before the current one.
-* The suffix '@{upstream}' to a ref (short form 'ref@{u}') refers to
+* The suffix '@\{upstream\}' to a ref (short form 'ref@\{u\}') refers to
the branch the ref is set to build on top of. Missing ref defaults
to the current branch.
--
1.7.0.rc2.178.g109e1
^ permalink raw reply related
* Re: RFC: git sync
From: Sergio @ 2010-02-10 16:39 UTC (permalink / raw)
To: git
In-Reply-To: <m3wryl8lkp.fsf@localhost.localdomain>
> Why not use the recpie from GitFaq:
> "How would I use "git push" to sync out of a host that I cannot pull from?"
>
http://git.wiki.kernel.org/index.php/GitFaq#How_would_I_use_.22git_push.22_to_sync_out_of_a_host_that_I_cannot_pull_from.3F
>
Hi, to follow that recipe with more than one satellite, all sharing the same
config, it would be just great to be able to put $hostname in .git-config, e.g.
[remote "mothership"]
url = <url>
push = master:refs/remotes/$hostname/master
Would there be any potential problem with that?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox