* Re: qgit idea: interface for cherry-picking
From: Junio C Hamano @ 2006-07-04 6:41 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550607032322jdf3bc79l3f41c292ebb6d3f7@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
>> The main question is what you would let your users do and how
>> you would guide them through the process, when the application
>> of an earlier patch in the series fails. I think it is a
>> secondary implementation detail which of "git-am", "git-am
>> --fail" or "git-apply" to implement that process.
>
> QGit is not supposed to be a GUI replacement of git UI. QGit only let
> users quickly call some commonly used commands. The process of error
> recovering, conflicts resolve and any other complication that could
> involve more the one main flow of processing are outside the scope.
> QGit simply leaves the job to native git tools any time there
> something 'outside tha main flow'.
Yes, either you (1) need to make sure the user is aware what
underlying git commands QGit runs for them, so that the user
knows what workflow to follow when the procedure needs to go
manual, or (2) hide the underlying git commands QGit runs for
users, but then you need to make QGit aware of what workflow to
follow when the procedure needs to go manual, and guide the user
through that workflow. I think either is fine approach;
personally I prefer transparent tools that does (1), which is
the impression I am getting from your description of QGit.
If you take route (1), using "am --fail" number of times
involves QGit runs "am --fail" once, guide user to fix things up
_and_ give control back to QGit, then you run the next "am
--fail", etc, which would be quite cumbersome to implement. But
running multiple am and do reset soft to roll back needed number
of parents might be easier option to implement in QGit, but you
still have the same "you give the control to the user but then
you have to take the control away to proceed" problem when the
patch does not apply cleanly somewhere (you let the user to hand
resolve and say "am --resolved", but then when the series is
depleted, somebody has to run "reset --soft" to roll N commits
back to realize what you wanted to do, so at that point QGit
somehow needs to take control back).
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Jakub Narebski @ 2006-07-04 6:39 UTC (permalink / raw)
To: git
In-Reply-To: <e5bfff550607032322jdf3bc79l3f41c292ebb6d3f7@mail.gmail.com>
Marco Costalba wrote:
> QGit is not supposed to be a GUI replacement of git UI. QGit only let
> users quickly call some commonly used commands. [...]
It's a pity. Doing some of commands from visual history viewer, with view of
branches etc. would be so much easier: like bisect, rebasing, cherry
picking, reverting a commit...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Marco Costalba @ 2006-07-04 6:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5cmqwv3.fsf@assigned-by-dhcp.cox.net>
On 7/3/06, Junio C Hamano <junkio@cox.net> wrote:
>
> If you had a series of patches chosen inside your GUI and
> squash-apply them all, two full am with soft reset to the
> original state would be the easiest, if and only if both patch
> applications do not fail. If patch A does not apply for
> whatever reason, you have to guide your user through the patch
> adjustment process before applying B, regardless of the reason
> why the patch application failed (either A did not apply
> cleanly, or you gave --fail to the command).
>
> The main question is what you would let your users do and how
> you would guide them through the process, when the application
> of an earlier patch in the series fails. I think it is a
> secondary implementation detail which of "git-am", "git-am
> --fail" or "git-apply" to implement that process.
>
QGit is not supposed to be a GUI replacement of git UI. QGit only let
users quickly call some commonly used commands. The process of error
recovering, conflicts resolve and any other complication that could
involve more the one main flow of processing are outside the scope.
QGit simply leaves the job to native git tools any time there
something 'outside tha main flow'.
So in case a patch does not apply a message feedback is returned and
the process is terminated. All the not qgit generated intermediate
files are left at their places and is up to the user fix the things
up, possibly using native git commands.
QGit does not play magic. If something goes wrong it simply stops.
Marco
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Junio C Hamano @ 2006-07-04 6:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607032213030.12404@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Looking closer, I suspect a big part of it is that
>
> git-ls-remote $upload_pack --tags "$remote" |
> sed -ne 's|^\([0-9a-f]*\)[ ]\(refs/tags/.*\)^{}$|\1 \2|p' |
> while read sha1 name
> do
> ..
> done
>
> loop.
Yes indeed. Maybe we can do this loop in Perl. Doing the whole
thing in C is another option but it would be somewhat painful,
unless we can deprecate all transport but git native protocols.
On the other hand, 5 seconds may not matter that much in practice.
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Linus Torvalds @ 2006-07-04 5:53 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1151990980.4723.132.camel@neko.keithp.com>
On Mon, 3 Jul 2006, Keith Packard wrote:
>
> 361 /usr/bin/expr
>
> someone sure likes 'expr'...
Heh. That's a very Junio thing to do.
Junio seems to like
if expr "z$string" : "z<regexp>" >/dev/null
then
..
and I think he explained it as being the way old-fashioned users do it.
Linus
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Junio C Hamano @ 2006-07-04 5:47 UTC (permalink / raw)
To: gitzilla; +Cc: git, torvalds
In-Reply-To: <44A9E6AE.10508@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> This demonstrates a problem with git-merge-base.
>
> +# Setup for second test set
> +#
> +# PL PR
> +# / \/ \
> +# L2 C2 R2
> +# | | |
> +# L1 C1 R1
> +# | | |
> +# L0 C0 R0
> +# \ | /
> +# S
Cute.
This is a good demonstration that merge-base may not give you
minimal set for pathological cases. If you want to be through
you could traverse everything to make sure we do not say 'S' is
relevant, but that is quite expensive, so I think there will
always be artifacts of horizon effect like this no matter how
you try to catch it (didn't I keep saying that already?).
However, I do not think it is really a "problem". At least what
"merge-base --all" did not miss any, that should be OK.
I think the practical way to proceed is to say that the test
condition should really check that we do not _omit_ C2 in the
merge-base --all output.
^ permalink raw reply
* Re: Compression speed for large files
From: Joachim Berdal Haga @ 2006-07-04 5:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, git
In-Reply-To: <Pine.LNX.4.64.0607031556480.12404@g5.osdl.org>
Linus Torvalds wrote:
>
> On Tue, 4 Jul 2006, Joachim Berdal Haga wrote:
>> Here's a test with "time gzip -[169] -c file >/dev/null". Random data
>> from /dev/urandom, kernel headers are concatenation of *.h in kernel
>> sources. All times in seconds, on my puny home computer (1GHz Via Nehemiah)
>
> That "Via Nehemiah" is probably a big part of it.
>
> I think the VIA Nehemiah just has a 64kB L2 cache, and I bet performance
> plummets if the tables end up being used past that.
Not really. The numbers in my original post were from a Intel core-duo,
they were: 158/18/6 s for comparable (but larger) data.
And on a P4 1.8GHz with 512kB L2, the same 23MB data file compresses in
28.1/5.9/1.3 s. That's a factor 22 slowest/fastest; the VIA was only
factor 18, so the difference is actually *larger*.
-j.
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Linus Torvalds @ 2006-07-04 5:36 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1151989503.4723.126.camel@neko.keithp.com>
On Mon, 3 Jul 2006, Keith Packard wrote:
>
> 5 Start: 21:59:01.584648000
> 66 After args: 21:59:01.605987000
> 248 fetch_main() start: 21:59:02.408559000
> 339 fetch_main() before fetch-pack: 21:59:03.293228000
> 387 fetch_main() done: 21:59:04.784388000
> 422 After tag following: 21:59:05.311439000
> 438 All done: 21:59:05.315338000
>
> fetch-pack itself took 0.421 seconds (measured with time(1)).
>
> Looks like the bulk of the time here is caused by simple shell
> processing overhead, some of which scales with the number of heads and
> tags to track.
Ahh.. Do you have tons of tags at the other end?
Looking closer, I suspect a big part of it is that
git-ls-remote $upload_pack --tags "$remote" |
sed -ne 's|^\([0-9a-f]*\)[ ]\(refs/tags/.*\)^{}$|\1 \2|p' |
while read sha1 name
do
..
done
loop.
With a lot of tags, the shell overhead there can indeed be pretty
disgusting. And I was wrong - I thought it would do that git-ls-remote
only if the first time around we noticed that we would need to, but we do
actually do it all the time that we're fetching any new branches.
The sad part is that we really already got the list once, we just never
saved it away (ie "git-fetch-pack" actually _knows_ what the tags at the
other end are, and also knows which tags we already have, so if we made
git-fetch-pack just create that list and save it off, all the overhead
would just go away).
And yes, the shell script loops are really really simple, but some of them
are actually quadratic in the number of refs (O(local*remote)). If this
was a C program, we'd never even care, but with shell, the thing is slow
enough that having even a modest amount of tags and refs is going to just
make it waste a lot of time in shell scripting.
We already do a lot of the infrastructure for "git fetch" in C - the
remotes parsing etc is all things that "git fetch" used to share with "git
push", but "git push" has been a builtin C program for a while now. I
suspect we should just do the same to "git fetch", which would make all
these issues just totally go away.
Linus
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Keith Packard @ 2006-07-04 5:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: keithp, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607032115340.12404@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 837 bytes --]
On Mon, 2006-07-03 at 21:19 -0700, Linus Torvalds wrote:
> Well, that's still strange. What takes 4.2 seconds then?
$ strace -e trace=execve -f git-fetch 2>&1 | grep execve | sed -e 's/^.*execve("//' -e 's/".*$//' | sort | uniq -c | sort -n
1 /bin/rm
1 /home/keithp/bin/git
1 /home/keithp/bin/git-fetch
1 /home/keithp/bin/git-fetch-pack
1 /home/keithp/bin/git-ls-remote
1 /home/keithp/bin/git-peek-remote
1 /usr/bin/sort
3 /bin/sed
4 /home/keithp/bin/git-repo-config
30 /bin/mkdir
30 /home/keithp/bin/git-cat-file
30 /home/keithp/bin/git-check-ref-format
30 /home/keithp/bin/git-merge-base
30 /usr/bin/dirname
64 /home/keithp/bin/git-rev-parse
361 /usr/bin/expr
someone sure likes 'expr'...
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Keith Packard @ 2006-07-04 5:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: keithp, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607032115340.12404@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 865 bytes --]
On Mon, 2006-07-03 at 21:19 -0700, Linus Torvalds wrote:
> Can you instrument your "git-fetch.sh" script (just add random
>
> (echo $LINENO ; date) >&2
>
> lines all over) to see what is so expensive?
5 Start: 21:59:01.584648000
66 After args: 21:59:01.605987000
248 fetch_main() start: 21:59:02.408559000
339 fetch_main() before fetch-pack: 21:59:03.293228000
387 fetch_main() done: 21:59:04.784388000
422 After tag following: 21:59:05.311439000
438 All done: 21:59:05.315338000
fetch-pack itself took 0.421 seconds (measured with time(1)).
Looks like the bulk of the time here is caused by simple shell
processing overhead, some of which scales with the number of heads and
tags to track.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Keith Packard @ 2006-07-04 4:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: keithp, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607032039010.12404@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]
On Mon, 2006-07-03 at 20:40 -0700, Linus Torvalds wrote:
> "And, it's painfully slow, even when the repository is up to date"
>
> and gave a 17-second time.
It's faster this evening, down to 8 seconds using ssh and 4 seconds
using git. I clearly need to force use of the git protocol. Anyone else
like the attached patch?
---
connect.c | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/connect.c b/connect.c
index 9a87bd9..e74eddc 100644
--- a/connect.c
+++ b/connect.c
@@ -303,6 +303,7 @@ enum protocol {
PROTO_LOCAL = 1,
PROTO_SSH,
PROTO_GIT,
+ PROTO_GIT_SSH,
};
static enum protocol get_protocol(const char *name)
@@ -312,9 +313,9 @@ static enum protocol get_protocol(const
if (!strcmp(name, "git"))
return PROTO_GIT;
if (!strcmp(name, "git+ssh"))
- return PROTO_SSH;
+ return PROTO_GIT_SSH;
if (!strcmp(name, "ssh+git"))
- return PROTO_SSH;
+ return PROTO_GIT_SSH;
die("I don't handle protocol '%s'", name);
}
@@ -572,6 +573,14 @@ static void git_proxy_connect(int fd[2],
close(pipefd[1][0]);
}
+/* returns whether the specified command can be interpreted by the
daemon */
+int git_is_daemon_command (const char *prog)
+{
+ if (!strcmp("git-upload-pack", prog))
+ return 1;
+ return 0;
+}
+
/*
* Yeah, yeah, fixme. Need to pass in the heads etc.
*/
@@ -641,7 +650,8 @@ int git_connect(int fd[2], char *url, co
*ptr = '\0';
}
- if (protocol == PROTO_GIT) {
+ if (protocol == PROTO_GIT ||
+ (protocol == PROTO_GIT_SSH && git_is_daemon_command (prog))) {
/* These underlying connection commands die() if they
* cannot connect.
*/
@@ -678,7 +688,7 @@ int git_connect(int fd[2], char *url, co
close(pipefd[0][1]);
close(pipefd[1][0]);
close(pipefd[1][1]);
- if (protocol == PROTO_SSH) {
+ if (protocol == PROTO_SSH || protocol == PROTO_GIT_SSH) {
const char *ssh, *ssh_basename;
ssh = getenv("GIT_SSH");
if (!ssh) ssh = "ssh";
--
1.4.1.g8fced-dirty
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: git-fetch per-repository speed issues
From: Linus Torvalds @ 2006-07-04 4:19 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1151985747.4723.102.camel@neko.keithp.com>
On Mon, 3 Jul 2006, Keith Packard wrote:
>
> Yeah, it says that only once. And, it runs the fetch-pack in about .5
> seconds. And, now the whole process completes in 4.7 seconds; perhaps
> the remote server is less loaded than earlier this afternoon?
Well, that's still strange. What takes 4.2 seconds then?
> > And then it should leave a "fetch.trace" file in your working directory,
> > which should show where that _one_ thing spends its time.
>
> It looks boring to me and spent 0.55 from start to finish. I can send
> along the whole trace if you have an acute desire to peer at it.
No, the 0.5 seconds is what I _expected_. There's something strange going
on in your git fetch that it takes any longer than that.
Can you instrument your "git-fetch.sh" script (just add random
(echo $LINENO ; date) >&2
lines all over) to see what is so expensive?
That fetch-pack really should be the most expensive part by far (and half
a second sounds right), but it clearly isn't. At 4.7s, your fetch is still
taking about ten times longer than it _should_.
Linus
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Keith Packard @ 2006-07-04 4:02 UTC (permalink / raw)
To: Linus Torvalds, Git Mailing List; +Cc: keithp
In-Reply-To: <Pine.LNX.4.64.0607032008590.12404@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
On Mon, 2006-07-03 at 20:21 -0700, Linus Torvalds wrote:
> Keithp, can you try this trivial patch? It _should_ say something like
Yeah, it says that only once. And, it runs the fetch-pack in about .5
seconds. And, now the whole process completes in 4.7 seconds; perhaps
the remote server is less loaded than earlier this afternoon? It's also
possible that I was running old git bits here, but I don't think so.
> And then it should leave a "fetch.trace" file in your working directory,
> which should show where that _one_ thing spends its time.
It looks boring to me and spent 0.55 from start to finish. I can send
along the whole trace if you have an acute desire to peer at it.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Additional merge-base tests
From: A Large Angry SCM @ 2006-07-04 3:55 UTC (permalink / raw)
To: Junio C Hamano, git
Signed-off-by: A Large Angry SCM <gitzilla@gmail.com>
---
This demonstrates a problem with git-merge-base.
t6010-merge-base.sh | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+)
diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
index 1dce123..9a815bd 100755
--- a/t/t6010-merge-base.sh
+++ b/t/t6010-merge-base.sh
@@ -44,6 +44,31 @@ A=$(doit 1 A $B)
G=$(doit 7 G $B $E)
H=$(doit 8 H $A $F)
+# Setup for second test set
+#
+# PL PR
+# / \/ \
+# L2 C2 R2
+# | | |
+# L1 C1 R1
+# | | |
+# L0 C0 R0
+# \ | /
+# S
+
+S=$(doit 0 S)
+C0=$(doit -3 C0 $S)
+L0=$(doit 2 L0 $S)
+R0=$(doit 2 R0 $S)
+C1=$(doit -2 C1 $C0)
+L1=$(doit 3 L1 $L0)
+R1=$(doit 3 R1 $R0)
+C2=$(doit -1 C2 $C1)
+L2=$(doit 4 L2 $L1)
+R2=$(doit 4 R2 $R1)
+PL=$(doit 1 PL $L2 $C2)
+PR=$(doit 1 PR $C2 $R2)
+
test_expect_success 'compute merge-base (single)' \
'MB=$(git-merge-base G H) &&
expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/B"'
@@ -56,4 +81,12 @@ test_expect_success 'compute merge-base
'MB=$(git-show-branch --merge-base G H) &&
expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/B"'
+test_expect_success 'compute merge-base (single)' \
+ 'MB=$(git-merge-base PL PR) &&
+ expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/C2"'
+
+test_expect_success 'compute merge-base (all)' \
+ 'MB=$(git-merge-base --all PL PR) &&
+ expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/C2"'
+
test_done
^ permalink raw reply related
* Re: git-fetch per-repository speed issues
From: Linus Torvalds @ 2006-07-04 3:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsllinj1m.fsf@assigned-by-dhcp.cox.net>
On Mon, 3 Jul 2006, Junio C Hamano wrote:
>
> Isn't that because the repository have 32 subprojects, totally
> unrelated content-wise? If you have real stuff to pull from
> there your pack generation needs to do 32 time as much work as
> you would for a single head in that case.
No, Keith said this was for the case where the fetching repository is
already totally up-to-date:
"And, it's painfully slow, even when the repository is up to date"
and gave a 17-second time.
Linus
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Junio C Hamano @ 2006-07-04 3:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607032008590.12404@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Ok, a "git fetch" really shouldn't take any longer than a single
> connection. However, the fact that you have 32 heads, and it takes pretty
> close to _exactly_ 32 times 0.410 seconds (32*0.410s = 13.1s) makes me
> suspect that "git fetch" is just broken and fetches one branch at a time.
>
> Which would be just stupid.
>
> But look as I might, I see only that one "git-fetch-pack" in git-fetch.sh
> that should trigger. Once. Not 32 times. But your timings sure sound like
> it's doing a _lot_ more than it should.
>
> Junio, any ideas?
Isn't that because the repository have 32 subprojects, totally
unrelated content-wise? If you have real stuff to pull from
there your pack generation needs to do 32 time as much work as
you would for a single head in that case.
If you are discussing "peek-remote runs, find out the 32 heads
are all up to date and no pack is generated" case, then you are
right. There is one single fetch-pack to grab the specified
heads, and after that, an optional single ls-remote and
fetch-pack runs only once to follow all new tags.
^ permalink raw reply
* Re: Why's Git called Git ?
From: Linus Torvalds @ 2006-07-04 3:28 UTC (permalink / raw)
To: Aaron Gray; +Cc: Git Mailing List
In-Reply-To: <013001c69f04$ae4e2400$0200a8c0@amd2500>
On Tue, 4 Jul 2006, Aaron Gray wrote:
>
> Why the name I could not find any answer in the documentation ?
It's really quite random. It needs to be a two- or three-letter thing just
because I end up typing a lot.
My favourite explanation is "I name all my projects after myself: first
'Linux', now 'git'".
Which only makes sense if you know british slang.
The runner up was "Because 'twerp' was too hard to type".
But really, there's not a lot of real thinking behind it. The made-up
acronym was "global information tracker", but that's a pretty bad excuse
too.
It just happened. Don't ask me why. All the explanations are really made
up after the fact.
Linus
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Linus Torvalds @ 2006-07-04 3:21 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <1151973438.4723.70.camel@neko.keithp.com>
On Mon, 3 Jul 2006, Keith Packard wrote:
> On Mon, 2006-07-03 at 16:14 -0700, Linus Torvalds wrote:
> >
> > Well, you could use multiple branches in the same repository, even if they
> > are totally unrealated. That would allow you to fetch them all in one go.
>
> I'd like to avoid this; the hope is that most people won't ever need to
> look at most repositories; it would be somewhat like having glibc in the
> same repo as the kernel...
Sure, understood. I'm just saying that if you want to fetch in one go,
it's one possibility.
However, your setup has something else seriously wrong.
> Yeah, I tried with the git protocol and it's a few seconds faster (about
> 14 seconds instead of 17). Ick.
That's -still- about 13 seconds too much.
> I think it might have something to do with the number of heads we're
> tracking.
It really shouldn't matter. You get all the heads in one go with a single
connection, so if 32 heads takes 32 times longer, there's something wrong.
> > Also, one thing to try is to just do
> >
> > strace -Ttt git-peek-remote ...
>
> That's plenty fast, 0.410 seconds, with nothing ugly in the strace.
Ok, a "git fetch" really shouldn't take any longer than a single
connection. However, the fact that you have 32 heads, and it takes pretty
close to _exactly_ 32 times 0.410 seconds (32*0.410s = 13.1s) makes me
suspect that "git fetch" is just broken and fetches one branch at a time.
Which would be just stupid.
But look as I might, I see only that one "git-fetch-pack" in git-fetch.sh
that should trigger. Once. Not 32 times. But your timings sure sound like
it's doing a _lot_ more than it should.
Junio, any ideas?
Keithp, can you try this trivial patch? It _should_ say something like
Fetching
refs/heads/master
refs/heads/...
refs/heads/...
...
refs/heads/... from git://..../...
and more importantly, it should say so only once.
And then it should leave a "fetch.trace" file in your working directory,
which should show where that _one_ thing spends its time.
Linus
----
diff --git a/git-fetch.sh b/git-fetch.sh
index 48818f8..4739202 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -339,6 +339,8 @@ fetch_main () {
( : subshell because we muck with IFS
IFS=" $LF"
(
+ echo "Fetching $rref from $remote" >&2
+ strace -o fetch.trace -Ttt \
git-fetch-pack $exec $keep --thin "$remote" $rref || echo failed "$remote"
) |
while read sha1 remote_name
^ permalink raw reply related
* Re: git-fetch per-repository speed issues
From: Linus Torvalds @ 2006-07-04 3:07 UTC (permalink / raw)
To: Jeff King; +Cc: Keith Packard, Git Mailing List
In-Reply-To: <20060704002138.GB5716@coredump.intra.peff.net>
On Mon, 3 Jul 2006, Jeff King wrote:
>
> Fetching by ssh actually makes two ssh connections (the second is to
> grab tags).
True. Although that should happen only if there are any new tags.
Linus
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Ryan Anderson @ 2006-07-04 1:55 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Keith Packard, Git Mailing List
In-Reply-To: <20060704014441.GB9061@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]
Jeff King wrote:
> On Mon, Jul 03, 2006 at 06:22:26PM -0700, Ryan Anderson wrote:
>
>
>> You can have multiple source trees, one per 'branch' (which is a bit of
>> a bad term here), and have completely unrelated things in the branches.
>>
>> See, for an example, the main Git repo, which has the "man", "html", and
>> "todo" branches, logically distinct and (somewhat) unrelated to the main
>> branch tucked away in "master".
>>
>
> Right, I know, but my complaint is that I can't then turn that into a
> directory hierarchy of .../man, .../html, .../todo that are all checked
> out at the same time (there are obviously ways of playing with it, say
> by setting GIT_DIR and doing a checkout in those directories, but then I
> can't use git in the normal way).
>
> The best I can come up with is having man, html, and todo repos pointing
> to the one (now local) repo which contains everything. But then pushing
> is a two-step process.
>
>
Hrm, if I understand CVS at all, the old workflow was "cvsup a copy of
the repository, update a working tree against that", which is, I think,
actually even worse than the Git equivalent, since you can't reliably
even commit to that local clone of the CVS repository.
What am I missing?
You can still push directly upstream, I suppose, and just do 2-stage
pulls down.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* New and hot I think, yes. Be delighted with
From: Marla @ 2006-07-04 1:54 UTC (permalink / raw)
To: git
How are you bro ?
You crave to shoot like a film star…
Show your girl a huge explosion as I used to do
Have you some doubt?
Check up here: http://www.basszass.com
We thank you for being our customer!
^ permalink raw reply
* Re: [PATCH] send-email: do not barf when Term::ReadLine does not like your terminal
From: Ryan Anderson @ 2006-07-04 1:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsgn1ue8.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]
Junio C Hamano wrote:
> As long as we do not need to readline from the terminal, we
> should not barf when starting up the program. Without this
> patch, t9001 test on Cygwin occasionally died with the following
> error message:
>
> Unable to get Terminal Size. The TIOCGWINSZ ioctl didn't work. The COLUMNS and LINES environment variables didn't work. The resize program didn't work. at /usr/lib/perl5/vendor_perl/5.8/cygwin/Term/ReadKey.pm line 362.
> Compilation failed in require at /usr/lib/perl5/vendor_perl/5.8/Term/ReadLine/Perl.pm line 58.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
>
> * I do not use send-email myself that often so extra sets of
> eyeballs are appreciated.
>
Looks fine to me.
Acked-by: Ryan Anderson <ryan@michonline.com>
(I personally would have put the package declaration at the end of the
file, but it's not significant enough for me to send a patch, heh.)
> git-send-email.perl | 18 +++++++++++++++++-
> t/t9001-send-email.sh | 11 +++++++----
> 2 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index c5d9e73..b04b8f4 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -22,6 +22,17 @@ use Term::ReadLine;
> use Getopt::Long;
> use Data::Dumper;
>
> +package FakeTerm;
> +sub new {
> + my ($class, $reason) = @_;
> + return bless \$reason, shift;
> +}
> +sub readline {
> + my $self = shift;
> + die "Cannot use readline on FakeTerm: $$self";
> +}
> +package main;
> +
> # most mail servers generate the Date: header, but not all...
> $ENV{LC_ALL} = 'C';
> use POSIX qw/strftime/;
> @@ -46,7 +57,12 @@ my $smtp_server;
> # Example reply to:
> #$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
>
> -my $term = new Term::ReadLine 'git-send-email';
> +my $term = eval {
> + new Term::ReadLine 'git-send-email';
> +};
> +if ($@) {
> + $term = new FakeTerm "$@: going non-interactive";
> +}
>
> # Begin by accumulating all the variables (defined above), that we will end up
> # needing, first, from the command line:
> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
> index a61da1e..e9ea33c 100755
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -25,10 +25,13 @@ test_expect_success \
> git add fake.sendmail
> GIT_AUTHOR_NAME="A" git commit -a -m "Second."'
>
> -test_expect_success \
> - 'Extract patches and send' \
> - 'git format-patch -n HEAD^1
> - git send-email -from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" ./0001*txt'
> +test_expect_success 'Extract patches' '
> + patches=`git format-patch -n HEAD^1`
> +'
> +
> +test_expect_success 'Send patches' '
> + git send-email -from="Example <nobody@example.com>" --to=nobody@example.com --smtp-server="$(pwd)/fake.sendmail" $patches 2>errors
> +'
>
> cat >expected <<\EOF
> !nobody@example.com!
>
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Jeff King @ 2006-07-04 1:44 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Linus Torvalds, Keith Packard, Git Mailing List
In-Reply-To: <44A9C2D2.6010409@michonline.com>
On Mon, Jul 03, 2006 at 06:22:26PM -0700, Ryan Anderson wrote:
> You can have multiple source trees, one per 'branch' (which is a bit of
> a bad term here), and have completely unrelated things in the branches.
>
> See, for an example, the main Git repo, which has the "man", "html", and
> "todo" branches, logically distinct and (somewhat) unrelated to the main
> branch tucked away in "master".
Right, I know, but my complaint is that I can't then turn that into a
directory hierarchy of .../man, .../html, .../todo that are all checked
out at the same time (there are obviously ways of playing with it, say
by setting GIT_DIR and doing a checkout in those directories, but then I
can't use git in the normal way).
The best I can come up with is having man, html, and todo repos pointing
to the one (now local) repo which contains everything. But then pushing
is a two-step process.
-Peff
^ permalink raw reply
* Re: [PATCH 0/2] Fix handling of merges in git-annotate
From: Ryan Anderson @ 2006-07-04 1:34 UTC (permalink / raw)
To: Ryan Anderson; +Cc: junkio, git
In-Reply-To: <11519766021208-git-send-email-ryan@michonline.com>
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
Ryan Anderson wrote:
> This 2-patch series is a major overhaul to the way git-annotate calculates the blame for each line.
>
> Instead of parsing each diff in reverse, this uses the output from "git
> diff-tree --combined", so that merges can be handled sanely.
>
I forgot:
Please pull from http://h4x0r5.com/~ryan/git/ryan.git annotate-upstream
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* [PATCH 0/2] Fix handling of merges in git-annotate
From: Ryan Anderson @ 2006-07-04 1:30 UTC (permalink / raw)
To: junkio; +Cc: git
This 2-patch series is a major overhaul to the way git-annotate calculates the blame for each line.
Instead of parsing each diff in reverse, this uses the output from "git
diff-tree --combined", so that merges can be handled sanely.
Ryan Anderson:
annotate: Support annotation of files on other revisions.
annotate: Correct most merge following to annotate correctly.
git-annotate.perl | 197 ++++++++++++++++++++++++++++++++++++---------------
t/t8001-annotate.sh | 6 ++
2 files changed, 145 insertions(+), 58 deletions(-)
^ 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