* Re: git-fetch per-repository speed issues
From: Andreas Ericsson @ 2006-07-04 11:10 UTC (permalink / raw)
To: Keith Packard; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <1151987441.4723.110.camel@neko.keithp.com>
Keith Packard wrote:
> 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?
Since it changes the current meaning of ssh+git, I'm not exactly
thrilled. However, "git/ssh" or "ssh/git" would work fine for me. The
slash-separator could be used to say "fetch over this, push over that",
so we can end up with any valid protocol to use for fetches and another
one to push over.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-cvsimport gets parents wrong for branches
From: Elrond @ 2006-07-04 11:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, git
In-Reply-To: <Pine.LNX.4.63.0607041007391.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Jul 04, 2006 at 10:09:18AM +0200, Johannes Schindelin wrote:
> 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).
Of couye in theory, (if cvs was used sanely), the base of
each branch should be a commit on the parent-branch. But as
we all know, cvs allows pathologic cases.
(My script doesn't create such a case, it's sanely
representable in git without any fake commits.)
So now for the patholigic cases (when they're solved, the
main issue is solved too):
Of course, the base version for a branch can be turned into
a tree (should be easy: cvsps's first changeset of the
branch has the previous revisions of each file).
This tree can also be turned into a fake commit...
just which parent should our new fake commit have?
My current simple answer is: The commit on the parent
branch with the most matching number of files, so that
the diff, that the fake commit introduces has the least
number of files.
In the non-patholoc case, the fake commit would introduce
no diff at all and should be dropped.
Of couse I have no idea, how hard it would be to implement
this. And in reality, it would be cvsps's job to do that.
Elrond
^ permalink raw reply
* Re: [PATCH] Teach rev-parse the ... syntax.
From: Johannes Schindelin @ 2006-07-04 10:50 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List, Junio C. Hamano
In-Reply-To: <873bdhbv4x.fsf@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 387 bytes --]
Hi,
On Tue, 4 Jul 2006, Santi Béjar wrote:
> + struct commit_list *exclude = get_merge_bases(a, b,1);
You never free_commit_list() exclude.
Side thought: we do not really support multiple ranges, do we? E.g.
git-rev-list HEAD~10..HEAD~8 HEAD^..
would not yield the intended result, right? (And same goes for ... ranges)
Maybe we should at least warn about that.
Ciao,
Dscho
^ permalink raw reply
* Re: git-cvsimport gets parents wrong for branches
From: Elrond @ 2006-07-04 10:46 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90607031615m2cafbf05q5922fb04eae72362@mail.gmail.com>
On Tue, Jul 04, 2006 at 11:15:47AM +1200, Martin Langhoff wrote:
> Elrond,
>
> you are right, the current git-cvsimport takes a very naive approach
> to determine where branches open from. It uses cvsps internally, which
> only reports on the ancestor branch, so we take the latest commit from
> the ancestor.
If there is no fix visible, it probably should be
documented, that git-cvsimport isn't the perfect solution,
so people aren't surprised.
> Parsecvs probably has a more sophisticated approach, have you tried it?
After finding the current correct git:-url [1] for it, I
noticed, that I need libgit for it (I use git from my
distribution), so I've postponed this.
Of course, you can use my script and try parsecvs yourself.
> If the cvs2svn documentation is not lying, it probably has the
> smartest/correctest implementation. For small-medium repos, you may be
> able to run cvs2svn and then import with git-svnimport.
I'll try that soon.
Elrond
[1] git://anongit.freedesktop.org/git/users/keithp/parsecvs
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Junio C Hamano @ 2006-07-04 10:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitzilla, git
In-Reply-To: <Pine.LNX.4.63.0607041019580.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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.
The problem ALASCM's example demonstrates does rely on clock
skews. The timestamps used in the example looked like this:
1 1
/ \/ \
4 -1 4
| | |
3 -2 3
| | |
2 -3 2
\ | /
0
The crucial clock skew the case relies on is that the tip of the
middle branch (-1) is older than the common commit (0). But the
topmost commits with timestamp 1 could be with timestamp 5 to
correct the clock skew and still make the example "fail".
5 5
/ \/ \
4 -1 4
| | |
3 -2 3
| | |
2 -3 2
\ | /
0
However, I am not sure how you are going to use that maximumSkew
variable. The evil owner of the middle branch may have started
running a "git am" to commit 4-patch series just when the
machine's clock jumped back by 3 seconds, at the pace of 1 patch
a second. Then he pushes '0' out on "master" branch, and the
three commits on top of that on "next" branch.
Two days later, two friends build left and right strands of
pearls based on the "master" branch of the evil owner of the
middle branch. Maybe they do that one patch a day. On the
fifth day, they both merge the "next" branch.
The point is that it does not require a very large clock skew to
trigger this.
^ permalink raw reply
* Re: Can't import Xenomai svn repo
From: Dennis Stosberg @ 2006-07-04 10:17 UTC (permalink / raw)
To: llandre; +Cc: git
In-Reply-To: <44AA2B50.4060403@dave-tech.it>
llandre wrote:
> 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
Looks like the repository is simply not accessible by http.
$ svn co http://svn.gna.org/xenomai/trunk
svn: PROPFIND request failed on '/xenomai/trunk'
svn: PROPFIND of '/xenomai/trunk': 405 Method Not Allowed (http://svn.gna.org)
git-svnimport imports a complete svn repository including its
branches and tags (as long as the svn repo follows the official
layout). So you would run it against the repository's root:
git svnimport svn://svn.gna.org/xenomai/
If you want to import/track the trunk only (and maybe commit to it),
git-svn from git's contrib is probably what you want.
Regards,
Dennis
^ permalink raw reply
* New And the results will impress your girl
From: Della @ 2006-07-04 9:47 UTC (permalink / raw)
To: godard
Nice to see you!
Prolong your ssex. You have small peniis? Add 3 inches in lenght! Find what you need here: http://abirtes.com/gal/ms
A black plum is as sweet as a white. Not to know is bad; not to wish to know is worse Every man has his price You can lead a horse to water but.. how?. A tidy house holds a bored woman.
^ 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
* 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
* 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] 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
* 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 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: 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
* [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: [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
* 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: 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] 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] 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: 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
* 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: 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
* 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: 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
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