* 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: 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: [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: 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: 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: 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: 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: 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: [PATCH] Additional merge-base tests
From: A Large Angry SCM @ 2006-07-04 6:41 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: torvalds
In-Reply-To: <7v3bdhoraa.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> 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?).
Not _that_ pathological in practice, given that you can't really depend
on the timestamps in a distributed SCM.
The problem is in mark_reachable_commits(); it is either superfluous or
it needs to parse_commit() those commits that haven't been parsed yet
that it needs to traverse.
> However, I do not think it is really a "problem". At least what
> "merge-base --all" did not miss any, that should be OK.
The degree of the problem is, admittedly, situational.
> 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.
I do not believe that the (current) code will miss any bases but it can
certainly return bases that are reachable from other bases.
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Jakub Narebski @ 2006-07-04 6:44 UTC (permalink / raw)
To: git
In-Reply-To: <20060704002138.GB5716@coredump.intra.peff.net>
Jeff King wrote:
> On Mon, Jul 03, 2006 at 04:14:10PM -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.
>
> One annoying thing about this is that you may want to have several of
> the branches checked out at a time (i.e., you want the actual directory
> structure of libXrandr/, Xorg/, etc). You could pull everything down
> into one repo and point small pseudo-repos at it with alternates, but I
> would think that would become a mess with pushes. You can do some magic
> with read-tree --prefix, but again, I'm not sure how you'd make commits
> on the correct branch. Is there an easier way to do this?
Write proper subprojects support for git, or pester someone to write it
(finally). See Subpro.txt in todo branch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* qgit idea: marking refs (heads and tags)
From: Jakub Narebski @ 2006-07-04 6:58 UTC (permalink / raw)
To: git
One thing I sorely lack in qgit as compared to gitk (and even gitweb[*1*])
is marking commits with refs (heads and tags, marked with different colors
or different shape marker). gitk currently uses markers in short log line
before text of commit summary, gitweb uses markers after (at the end) of
commit log summary. In qgit head commits are marked as such, but not to
which branche they belong[*2*].
And also somewhat (but to much lesser extent) showing explicitely sha1-ids
for commit, parents, tree, referenced object (in tag), to copy'n'paste to
shell.
[*1*] Currently _only_ in summary view IIRC, see e.g.
http://www.kernel.org/git/?p=git/git.git;a=summary
[*2*] gitk has also somewhat expensive "branches that commit belongs to" and
"closest tag(s) that are in lineage of this commit".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Jakub Narebski @ 2006-07-04 7:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vk66tna71.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> [...] (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).
Would it be easier if QGit for "am --squash" generated lightweight temporary
tag before first git-am, so one would need not to remember N for "reset
--soft"?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Junio C Hamano @ 2006-07-04 7:17 UTC (permalink / raw)
To: gitzilla; +Cc: git, torvalds
In-Reply-To: <44AA0DAE.1060308@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Junio C Hamano wrote:
>> 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
>>...
> Not _that_ pathological in practice, given that you can't really
> depend on the timestamps in a distributed SCM.
After I looked at the timestamps you assigned to these sequences
I fully agree they are not pathological at all. For each
"repository owner" who makes a single strand of pearls, time
seems to be flowing monotonically.
1 1
/ \/ \
4 -1 4
| | |
3 -2 3
| | |
2 -3 2
\ | /
0
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Junio C Hamano @ 2006-07-04 7:45 UTC (permalink / raw)
To: gitzilla; +Cc: git
In-Reply-To: <44AA0DAE.1060308@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
>> 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?).
>
> The problem is in mark_reachable_commits(); it is either superfluous
> or it needs to parse_commit() those commits that haven't been parsed
> yet that it needs to traverse.
Yes, you could traverse everything. But that is not practical.
We have known that the clean-up pass has this horizon effect,
and it is a compromise.
If you apply this testing patch on top of yours, you will see
that parsing more commits at that point makes the clean-up
pass go all the way down to the root commit.
We may alternatively not use the clean-up pass at all, but I
suspect that might give us many false positives. I don't
remember the details but I think we added it while fixing
merge-base in the real life situation.
It may be interesting to run tests on real merges (I believe the
kernel repository has a handful merges that have more than one
merge bases) to see how effective the current clean-up pass is.
It may turn out to be ineffective in practice, in which case we
could kill it off.
diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
index 9a815bd..4c6ed5c 100755
--- a/t/t6010-merge-base.sh
+++ b/t/t6010-merge-base.sh
@@ -89,4 +89,33 @@ test_expect_success 'compute merge-base
'MB=$(git-merge-base --all PL PR) &&
expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/C2"'
+# Setup third set
+#
+# S-U0-U1-U2-U3-U4
+# \ X
+# D0-D1-D2-D3-D4
+
+U0=$(doit 1 U0 $S)
+D0=$(doit 1 D0 $S)
+U1=$(doit 2 U1 $U0)
+D1=$(doit 2 D1 $D0)
+U2=$(doit 3 U2 $U1)
+D2=$(doit 3 D2 $D1)
+U3=$(doit 4 U3 $U2)
+D3=$(doit 4 D3 $D2)
+U4=$(doit 5 U4 $U3 $D3)
+D4=$(doit 5 D4 $D3 $U3)
+
+test_expect_success 'compute merge-base' '
+
+ git merge-base --all U4 D4 >out 2>err
+ if grep tags/S err
+ then
+ echo "went all the way down to S -- very unhappy"
+ false
+ else
+ echo "stopped before going too far"
+ fi
+'
+
test_done
diff --git a/merge-base.c b/merge-base.c
index 4856ca0..daab296 100644
--- a/merge-base.c
+++ b/merge-base.c
@@ -6,8 +6,35 @@ #define PARENT1 1
#define PARENT2 2
#define UNINTERESTING 4
+static void debug_list(struct commit_list *l, const char *msg)
+{
+ fprintf(stderr, "%s\n", msg);
+ while (l) {
+ char buf[1024];
+ int parsed;
+ struct commit *commit = l->item;
+ l = l->next;
+ parsed = commit->object.parsed;
+
+ if (parsed) {
+ pretty_print_commit(CMIT_FMT_ONELINE, commit,
+ ~0UL, buf, sizeof(buf), 7,
+ NULL, NULL);
+ }
+ else {
+ sprintf(buf, "git-name-rev %s 1>&2",
+ sha1_to_hex(commit->object.sha1));
+ system(buf);
+ strcpy(buf, sha1_to_hex(commit->object.sha1));
+ }
+ fprintf(stderr, "%d %d %s\n", commit->object.flags,
+ parsed, buf);
+ }
+}
+
static struct commit *interesting(struct commit_list *list)
{
+ debug_list(list, "in interesting()");
while (list) {
struct commit *commit = list->item;
list = list->next;
@@ -134,6 +161,9 @@ static void mark_reachable_commits(struc
/*
* Postprocess to fully contaminate the well.
*/
+ debug_list(list, "list at top of mark-reachable");
+ debug_list(result, "result at top of mark-reachable");
+
for (tmp = result; tmp; tmp = tmp->next) {
struct commit *c = tmp->item;
/* Reinject uninteresting ones to list,
@@ -142,10 +172,12 @@ static void mark_reachable_commits(struc
if (c->object.flags & UNINTERESTING)
commit_list_insert(c, &list);
}
+
while (list) {
struct commit *c = list->item;
struct commit_list *parents;
+ debug_list(list, "list in mark-reachable postprocessing");
tmp = list;
list = list->next;
free(tmp);
@@ -155,6 +187,15 @@ static void mark_reachable_commits(struc
* parse new ones (we already parsed all the relevant
* ones).
*/
+
+ /* Parsing object here which is a disaster;
+ * let's demonstrate it.
+ */
+#if 1
+ if (!c->object.parsed)
+ parse_commit(c);
+#endif
+
parents = c->parents;
while (parents) {
struct commit *p = parents->item;
@@ -164,6 +205,7 @@ static void mark_reachable_commits(struc
commit_list_insert(p, &list);
}
}
+ debug_list(result, "result in mark-reachable postprocessing");
}
}
@@ -196,6 +238,7 @@ static int merge_base(struct commit *rev
free(tmp);
if (flags == 3) {
insert_by_date(commit, &result);
+ debug_list(result, "a new result");
/* Mark parents of a found merge uninteresting */
flags |= UNINTERESTING;
@@ -218,6 +261,7 @@ static int merge_base(struct commit *rev
if (result->next && list)
mark_reachable_commits(result, list);
+ debug_list(result, "final result");
while (result) {
struct commit *commit = result->item;
result = result->next;
^ permalink raw reply related
* Re: [PATCH 2nd try] Make git-fmt-merge-msg a builtin
From: Johannes Schindelin @ 2006-07-04 7:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtaunwj1.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 3 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> >
> > ---
> > This retires git-fmt-merge-msg.perl, since it passes all the
> > tests, but removes the Perl version not now.
>
> There is no point not removing the script if you update git.c
> and Makefile to point at the new one.
I should have put PATH/RFC. I did not want to remove the script right
away, so people could compare outputs (like Martin did with
git-format-patch).
> We do not have a test specific for fmt-merge-msg, so it
> obviously passes all the tests ;-). A new one is attached.
Well, t4013 showed me two output bugs, but it evidently did not check for
merge.summary.
> I think we should extend boolean to accept 'yes' and 'no',
In that case, could we have "YesPlease", "oui", "si" and "da", too? ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Make clear_commit_marks() clean harder
From: Johannes Schindelin @ 2006-07-04 7:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607031552410.12404@g5.osdl.org>
Hi,
On Mon, 3 Jul 2006, Linus Torvalds wrote:
> On Mon, 3 Jul 2006, Johannes Schindelin wrote:
> >
> > Traversing is actually wrong. Clearing the marks does not mean to clear
> > them on commits we did not even mark!
>
> If we didn't mark them, then clearing them would be a no-op, so nobody
> really cares.
My point being: if we try to clear commits we could not have possibly
marked, because they were not yet parsed, this is wrong. Basically, I
wanted to make the same point as you:
> This is why it is _wrong_ to care about the "parsed" bit when clearing the
> flags.
I will have another look at the users of clear_commit_marks() tomorrow.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2nd try] Make git-fmt-merge-msg a builtin
From: Junio C Hamano @ 2006-07-04 7:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607040948170.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I should have put PATH/RFC. I did not want to remove the script right
> away, so people could compare outputs (like Martin did with
> git-format-patch).
Well the stuff is quite straightforward and I think we could fix
it in-tree while in "next".
>> I think we should extend boolean to accept 'yes' and 'no',
>
> In that case, could we have "YesPlease", "oui", "si" and "da", too? ;-)
Hai? Nah, that's too much.
^ permalink raw reply
* [PATCH] t8001-annotate: fix a bash-ism in this test
From: Eric Wong @ 2006-07-04 8:04 UTC (permalink / raw)
To: Ryan Anderson; +Cc: junkio, git
In-Reply-To: <11519766033852-git-send-email-ryan@michonline.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t8001-annotate.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t8001-annotate.sh b/t/t8001-annotate.sh
index 70e2ad2..3a6490e 100755
--- a/t/t8001-annotate.sh
+++ b/t/t8001-annotate.sh
@@ -8,8 +8,8 @@ PROG='git annotate'
test_expect_success \
'Annotating an old revision works' \
- '[ $(git annotate file master | awk "{print \$3}" | grep -c "^A$") == 2 ] && \
- [ $(git annotate file master | awk "{print \$3}" | grep -c "^B$") == 2 ]'
+ '[ $(git annotate file master | awk "{print \$3}" | grep -c "^A$") -eq 2 ] && \
+ [ $(git annotate file master | awk "{print \$3}" | grep -c "^B$") -eq 2 ]'
test_done
--
1.4.1.g4148
^ permalink raw reply related
* Re: git-cvsimport gets parents wrong for branches
From: Johannes Schindelin @ 2006-07-04 8:09 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Elrond, git
In-Reply-To: <46a038f90607031615m2cafbf05q5922fb04eae72362@mail.gmail.com>
Hi,
On Tue, 4 Jul 2006, Martin Langhoff wrote:
> It is pretty hard to get that one right in any case, as there are
> cases where the new branch starts from something that is not a commit
> in the parent (from GIT's perspective).
But it should be easy to introduce a faked commit, which just contains
those versions (and takes the newest commit touching any of these file
versions as branch point).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2nd try] Make git-fmt-merge-msg a builtin
From: Johannes Schindelin @ 2006-07-04 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk66tls5o.fsf@assigned-by-dhcp.cox.net>
Hai^H^H^HHi,
On Tue, 4 Jul 2006, Junio C Hamano wrote:
> >> I think we should extend boolean to accept 'yes' and 'no',
> >
> > In that case, could we have "YesPlease", "oui", "si" and "da", too? ;-)
>
> Hai? Nah, that's too much.
You know, I always wondered if we could introduce "perhaps", for us
procrastinators.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Make clear_commit_marks() clean harder
From: Junio C Hamano @ 2006-07-04 8:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607040951390.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> If we didn't mark them, then clearing them would be a no-op, so nobody
>> really cares.
>
> My point being: if we try to clear commits we could not have possibly
> marked, because they were not yet parsed, this is wrong.
While you say above is correct, object.parsed bit does not give
you enough information to decide if we could not have possibly
marked or not, because it is perfectly valid to mark a commit
that we have not parsed.
As Linus said in this thread already (I am rephrasing):
- When you have a commit object, which is parsed, you can tell
who its parents are; more importantly, at that point you have
access to the commit objects for the parents already, but they
may not have been parsed.
- If you can make a decision whether the parents of a commit
should be marked or not solely by looking at the commit, you
are allowed to do so before parsing these parents. The
commit you look at to make that decision has to be parsed for
you to know who the parents are, though.
Marking unparsed objects is a valid operation because even
unparsed objects have flags field that is retained when they are
later lazily parsed.
Right now, in the inner loop of the main loop of merge_base()
code, we parse each parent and insert it into the &list, but
instead we could parse commit (if not parsed yet) just before
taking its parents list in the outer loop. That way we would
parse the parents lazily and will have commits marked but still
not parsed.
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Johannes Schindelin @ 2006-07-04 8:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: gitzilla, git
In-Reply-To: <7vpsgllsnp.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 4 Jul 2006, Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
> >> 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?).
> >
> > The problem is in mark_reachable_commits(); it is either superfluous
> > or it needs to parse_commit() those commits that haven't been parsed
> > yet that it needs to traverse.
>
> Yes, you could traverse everything. But that is not practical.
> We have known that the clean-up pass has this horizon effect,
> and it is a compromise.
We could introduce a time.maximumSkew variable, and just walk only
that much further when traversing the commits.
So, if you do not trust your clients to have a proper ntp setup, just say
"I trust my peers to be off at most 1 day". That would save lots vs
traverse-everything.
Ciao,
Dscho
^ permalink raw reply
* Can't import Xenomai svn repo
From: llandre @ 2006-07-04 8:48 UTC (permalink / raw)
To: git
Hi all,
I tried to import Xenomai svn repo but the script failed:
git-svnimport -v -C xenomai.git http://svn.gna.org/xenomai/trunk
RA layer request failed: PROPFIND request failed on '/xenomai/trunk':
PROPFIND of '/xenomai/trunk': 405 Method Not Allowed
(http://svn.gna.org) at /usr/bin/git-svnimport line 135
Git version is 1.4.0.
Anybody can help me?
TIA,
llandre
DAVE Electronics System House - R&D Department
web: http://www.dave-tech.it
email: r&d2@dave-tech.it
^ permalink raw reply
* Re: [PATCH] t8001-annotate: fix a bash-ism in this test
From: Junio C Hamano @ 2006-07-04 8:46 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060704080424.GA31612@soma>
Thanks -- good catch.
^ permalink raw reply
* [PATCH] Teach rev-parse the ... syntax.
From: Santi Béjar @ 2006-07-04 9:02 UTC (permalink / raw)
To: Git Mailing List, Junio C. Hamano
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
I think this time the mail patch is OK, I've tested it.
builtin-rev-parse.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 5f5ade4..8d2beb2 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -331,14 +331,29 @@ int cmd_rev_parse(int argc, const char *
unsigned char end[20];
const char *next = dotdot + 2;
const char *this = arg;
+ int symmetric = *next == '.';
+
*dotdot = 0;
+ next += symmetric;
+
if (!*next)
next = "HEAD";
if (dotdot == arg)
this = "HEAD";
if (!get_sha1(this, sha1) && !get_sha1(next, end)) {
show_rev(NORMAL, end, next);
- show_rev(REVERSED, sha1, this);
+ show_rev(symmetric?NORMAL:REVERSED, sha1, this);
+ if (symmetric) {
+ struct commit *a, *b;
+ a = lookup_commit_reference(sha1);
+ b = lookup_commit_reference(end);
+ struct commit_list *exclude = get_merge_bases(a, b,1);
+ while (exclude) {
+ show_rev(REVERSED,
+ exclude->item->object.sha1,NULL);
+ exclude = exclude->next;
+ }
+ }
continue;
}
*dotdot = '.';
--
1.4.1.ge6c0-dirty
^ permalink raw reply related
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