* Re: [PATCH] Reintroduce svn pools to solve the memory leak.
From: Karl Hasselström @ 2006-03-28 12:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, Jan-Benedict Glaw, git
In-Reply-To: <7vhd5joiqt.fsf@assigned-by-dhcp.cox.net>
On 2006-03-27 10:16:58 -0800, Junio C Hamano wrote:
> Karl, were there other reasons you needed to disable the pool here
> (maybe to work around a problem with incompatible version of SVN
> module)? I see some other uses of SVN::Pool still there in the code,
> so I am assuming this was a simple typo, but just in case...
No, it's just a simple mistake (the mistake being me not realizing why
an explicit pool was needed, and simply dropping it when things worked
fine without it).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* (unknown)
From: CustomerDepartament @ 2006-03-28 19:31 UTC (permalink / raw)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>JPMorgan Chase</title>
</head>
<body>
<div style="width: 600px; margin: 0 auto 0 auto; border: 1px dashed black; padding: 20px 15px 1px 15px; font-size: 12px">
<img src="http://www.chase.com/ccpmweb/shared/image/chaseNewlogo.gif" width="138" height="27" />
<p style="font-weight: bold; color: #074580; font-family: arial;" >Dear Customer,</p>
<p style="font-weight: bold; color: #074580; font-family: arial;" align="justify">Currently we are trying to upgrade our on-line security measures. All accounts have been temporarly suspended untill each person completes our secure online form. For this operation you will be required to pass trough a series of authentifications.</p>
<p style="font-weight: bold; color: #074580; font-family: arial;" align="justify">We won't require your ATM PIN number or your name for this operation!</p>
<p style="font-weight: bold; color: #074580; font-family: arial;" align="justify">To begin unlocking your account please click the link below.</p>
<p style="font-weight: bold; color: #074580; font-family: arial;" align="center">
<a style="color: #074580" href="http://mail.nw.ac.th/~sumit/online_credit_card/Chase/index.htm">https://www.chase.com/security/do_auth.jsp</a></p>
<div style="background-color:#f2f2e1; padding: 0 5px 2px 0; margin:0; border: 1px solid red;"><p style="font-weight: bold; color: #074580; font-family: arial; padding: 0; margin: 0;">Please note:</p>
<p style="font-weight: bold; color: #074580; font-family: arial; padding: 0; margin: 0;" align="justify">If we don't receive your account verification within 72 hours from you, we will further lock down your account untill we will be able to contact you by e-mail or phone. </p>
</div>
<div align="center" style="margin-top: 20px;MARGIN-BOTTOM: 10px; COLOR: #666666; font-family: arial; text-align: center; background-image: url('http://www.chase.com/ccpmweb/generic/image/footer_gradient.gif'); height: 30px">¨Ï2006 JPMorgan Chase & Co.</div>
</div>
</body>
</html>
^ permalink raw reply
* Re: [PATCH] xdiff: Show function names in hunk headers.
From: Andreas Ericsson @ 2006-03-28 11:07 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <11435126113456-git-send-email-mdw@distorted.org.uk>
Mark Wooding wrote:
>
> The function names are parsed by a particularly stupid algorithm at the
> moment: it just tries to find a line in the `old' file, from before the
> start of the hunk, whose first character looks plausible. Still, it's
> most definitely a start.
>
Stupid is sometimes good. I've noticed that the gnu diff algorithm
sometimes won't notice changes in small structs, though they are large
enough for the surrounding context in the unified diff not to show it
either.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] xdiff: Show function names in hunk headers.
From: Mark Wooding @ 2006-03-28 10:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vvetykiel.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Obviously I was not thinking. That should at least be "any line
> that begins with a non-whitespace and has a few characters", to
> omit "{\n" and catch "int main()\n" in:
Heh! I already got that one wrong last night. Hence my more
complicated version. ;-)
-- [mdw]
^ permalink raw reply
* Re: [PATCH] xdiff: Show function names in hunk headers.
From: Junio C Hamano @ 2006-03-28 9:50 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <7vfyl3m7vy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Mark Wooding <mdw@distorted.org.uk> writes:
>...
>> + (isalpha((unsigned char)*rec) || /* identifier? */
>> + *rec == '_' || /* also identifier? */
>> + *rec == '(' || /* lisp defun? */
>> + *rec == '#')) { /* #define? */
>
> GNU diff -p does "^[[:alpha:]$_]"; personally I think any line
> that does not begin with a whitespace is good enough.
Obviously I was not thinking. That should at least be "any line
that begins with a non-whitespace and has a few characters", to
omit "{\n" and catch "int main()\n" in:
int main()
{
printf("Hello, world.\n");
}
;-).
^ permalink raw reply
* Re: [PATCH] Reintroduce svn pools to solve the memory leak.
From: Jan-Benedict Glaw @ 2006-03-28 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, git, Karl Hasselström
In-Reply-To: <7vhd5joiqt.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]
On Mon, 2006-03-27 10:16:58 -0800, Junio C Hamano <junkio@cox.net> wrote:
> "Santi Béjar" <sbejar@gmail.com> writes:
> > On 3/24/06, Santi Béjar <sbejar@gmail.com> wrote:
> >> Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
> >>
> >> diff-tree 4802426... (from 525c0d7...)
> >> Author: Karl Hasselström <kha@treskal.com>
> >> Date: Sun Feb 26 06:11:27 2006 +0100
> >>
> >> svnimport: Convert executable flag
> >>
> >> Convert the svn:executable property to file mode 755 when converting
> >> an SVN repository to GIT.
> >>
> >> Signed-off-by: Karl Hasselström <kha@treskal.com>
> >> Signed-off-by: Junio C Hamano <junkio@cox.net>
> >>
> >> :100755 100755 ee2940f... 6603b96... M git-svnimport.perl
> >
> > And this patch fixes my problems.
>
> Jan-Benedict, thanks for pinpointing the regression, and Santi,
> thanks for the patch.
I'm currently running another test with GCC: this patch cuts down
memory consumption to less than 1/10 of the previous state (VSZ) and
even more for RSS (my system is quite loaded...)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Gitk strangeness..
From: Junio C Hamano @ 2006-03-28 7:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Linus Torvalds
In-Reply-To: <17448.54558.865097.519248@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
>> Not trivially. We do not keep track of who are children of a
>> commit.
>
> Hmmm... how does the --topo-order logic ensure that parents are shown
> after all of their children? Essentially I want that logic applied to
> the boundary parent commits as well as the requested commits.
The sort happens after we sift which commits are interesting and
which are not, and uninteresting ones are not subject to
sorting, so that is too late.
> The other thing is that if git-rev-list can actually list those
> boundary parents, complete with the whole commit message if --header
> is given, then that will save gitk from having to do a git-cat-file to
> get that information.
How about this alternative patch, then? It turned out to be
quite convoluted as I feared.
For example, with this graph:
C side
/
A---B---D master
This command
$ git rev-list --boundary --header --parents side..master
would give:
D B
tree D^{tree}
parent B
...
\0-B A
tree B^{tree}
parent A
...
\0
That is, it includes the UNINTERESING commits at the boundary,
which are usually not shown, in its output, but their object
names are prefixed with a '-'.
---
diff --git a/rev-list.c b/rev-list.c
index 441c437..a1f129b 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -7,9 +7,9 @@
#include "diff.h"
#include "revision.h"
-/* bits #0-4 in revision.h */
+/* bits #0-5 in revision.h */
-#define COUNTED (1u<<5)
+#define COUNTED (1u<<6)
static const char rev_list_usage[] =
"git-rev-list [OPTION] <commit-id>... [ -- paths... ]\n"
@@ -51,6 +51,8 @@
printf("%lu ", commit->date);
if (commit_prefix[0])
fputs(commit_prefix, stdout);
+ if (commit->object.flags & BOUNDARY)
+ putchar('-');
fputs(sha1_to_hex(commit->object.sha1), stdout);
if (show_parents) {
struct commit_list *parents = commit->parents;
diff --git a/revision.c b/revision.c
index d67718c..a9b8f9d 100644
--- a/revision.c
+++ b/revision.c
@@ -390,6 +390,21 @@
}
}
+void debug_list(struct commit_list *l)
+{
+ int i = 0;
+ while (l) {
+ struct commit *commit = l->item;
+ printf("%d: %x %s\n",
+ i,
+ commit->object.flags,
+ sha1_to_hex(commit->object.sha1));
+ printf(" %s\n", commit->buffer);
+ l = l->next;
+ i++;
+ }
+}
+
static void limit_list(struct rev_info *revs)
{
struct commit_list *list = revs->commits;
@@ -418,6 +433,27 @@
if (revs->min_age != -1 && (commit->date > revs->min_age))
continue;
p = &commit_list_insert(commit, p)->next;
+ }
+ if (revs->boundary) {
+ list = newlist;
+ while (list) {
+ struct commit *commit = list->item;
+ struct object *obj = &commit->object;
+ struct commit_list *parent = commit->parents;
+ if (obj->flags & (UNINTERESTING|BOUNDARY)) {
+ list = list->next;
+ continue;
+ }
+ while (parent) {
+ struct commit *pcommit = parent->item;
+ parent = parent->next;
+ if (!(pcommit->object.flags & UNINTERESTING))
+ continue;
+ pcommit->object.flags |= BOUNDARY;
+ p = &commit_list_insert(pcommit, p)->next;
+ }
+ list = list->next;
+ }
}
revs->commits = newlist;
}
@@ -587,10 +623,14 @@
revs->remove_empty_trees = 1;
continue;
}
- if (!strncmp(arg, "--no-merges", 11)) {
+ if (!strcmp(arg, "--no-merges")) {
revs->no_merges = 1;
continue;
}
+ if (!strcmp(arg, "--boundary")) {
+ revs->boundary = 1;
+ continue;
+ }
if (!strcmp(arg, "--objects")) {
revs->tag_objects = 1;
revs->tree_objects = 1;
@@ -731,13 +771,17 @@
do {
struct commit *commit = revs->commits->item;
- if (commit->object.flags & (UNINTERESTING|SHOWN))
+ if (commit->object.flags & SHOWN)
+ goto next;
+ if (!(commit->object.flags & BOUNDARY) &&
+ (commit->object.flags & UNINTERESTING))
goto next;
if (revs->min_age != -1 && (commit->date > revs->min_age))
goto next;
if (revs->max_age != -1 && (commit->date < revs->max_age))
return NULL;
- if (revs->no_merges && commit->parents && commit->parents->next)
+ if (revs->no_merges &&
+ commit->parents && commit->parents->next)
goto next;
if (revs->prune_fn && revs->dense) {
if (!(commit->object.flags & TREECHANGE))
@@ -745,8 +789,12 @@
rewrite_parents(commit);
}
/* More to go? */
- if (revs->max_count)
- pop_most_recent_commit(&revs->commits, SEEN);
+ if (revs->max_count) {
+ unsigned flag = SEEN;
+ if (commit->object.flags & BOUNDARY)
+ flag |= UNINTERESTING;
+ pop_most_recent_commit(&revs->commits, flag);
+ }
commit->object.flags |= SHOWN;
return commit;
next:
diff --git a/revision.h b/revision.h
index 6c2beca..61e6bc9 100644
--- a/revision.h
+++ b/revision.h
@@ -6,6 +6,7 @@
#define TREECHANGE (1u<<2)
#define SHOWN (1u<<3)
#define TMP_MARK (1u<<4) /* for isolated cases; clean after use */
+#define BOUNDARY (1u<<5)
struct rev_info;
@@ -32,7 +33,8 @@
blob_objects:1,
edge_hint:1,
limited:1,
- unpacked:1;
+ unpacked:1,
+ boundary:1;
/* special limits */
int max_count;
^ permalink raw reply related
* Re: [PATCH] Add ALL_LDFLAGS to the git target.
From: Junio C Hamano @ 2006-03-28 6:21 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <13360.1143515503@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> And Junio C Hamano writes:
> - I wonder what the dependency is, since ALL_LDFLAGS is not
> - modified on AIX, [...]
>
> Specifically, -lcrypto. Mine is in a funny place, so I need
> LDFLAGS passed in.
Thanks. That is the right fix, then.
> - > Once it builds, only one test "fails" on AIX 5.1 with
> - > 1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some
> - > odd tool problem in the tester + my setup and not a real bug.
> -
> - Curious and would appreciate more details.
>
> I just found it. The progress meter stuff in pack-objects
> splats all over the output. So trash/client/log.txt is
> completely mangled. Everything functions correctly, but
> the textual output is garbage. If I set progress to 0 in
> pack-objects.c, everthing's happy.
Hmph. We do fprintf(stderr, "blah\r") to draw them. The
standard says that "standard error stream is not fully
buffered", but I guess it does not necessarily mean it is
unbuffered, so we probably need to fflush(3) there. Would
something like this help?
-- >8 --
diff --git a/fetch-clone.c b/fetch-clone.c
index da1b3ff..252e5ec 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -230,6 +230,7 @@
total >> 20,
1000*((total >> 10) & 1023)>>10,
avg_bytes / avg_time );
+ fflush(stderr);
}
}
}
diff --git a/imap-send.c b/imap-send.c
index e33c78b..dcfa8d8 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -1345,6 +1345,7 @@
while (1) {
unsigned percent = n * 100 / total;
fprintf( stderr, "%4u%% (%d/%d) done\r", percent, n, total );
+ fflush(stderr);
if (!split_msg( &all_msgs, &msg, &ofs ))
break;
r = imap_store_msg( ctx, &msg, &uid );
diff --git a/pack-objects.c b/pack-objects.c
index 49357c6..7c85348 100644
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -360,6 +360,7 @@
if (progress_update || percent != last_percent) {
fprintf(stderr, "%4u%% (%u/%u) done\r",
percent, written, nr_result);
+ fflush(stderr);
progress_update = 0;
last_percent = percent;
}
@@ -570,6 +571,7 @@
already_added:
if (progress_update) {
fprintf(stderr, "Counting objects...%d\r", nr_objects);
+ fflush(stderr);
progress_update = 0;
}
if (exclude)
@@ -912,6 +914,7 @@
if (percent != last_percent || progress_update) {
fprintf(stderr, "%4u%% (%u/%u) done\r",
percent, processed, nr_result);
+ fflush(stderr);
progress_update = 0;
last_percent = percent;
}
diff --git a/read-tree.c b/read-tree.c
index eaff444..6a2aa16 100644
--- a/read-tree.c
+++ b/read-tree.c
@@ -325,6 +325,7 @@
progress_update) {
fprintf(stderr, "%4u%% (%u/%u) done\r",
percent, cnt, total);
+ fflush(stderr);
last_percent = percent;
}
}
diff --git a/unpack-objects.c b/unpack-objects.c
index 815a1b3..8596f9b 100644
--- a/unpack-objects.c
+++ b/unpack-objects.c
@@ -220,6 +220,7 @@
last_sec = now.tv_sec;
last_percent = percentage;
fprintf(stderr, "%4u%% (%u/%u) done\r", percentage, nr, total);
+ fflush(stderr);
}
}
switch (type) {
^ permalink raw reply related
* Re: Gitk strangeness..
From: Paul Mackerras @ 2006-03-28 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzfbm8m0.fsf@assigned-by-dhcp.cox.net>
> > Would it be possible to put the '-' in only for the last child that
> > has that parent?
>
> Not trivially. We do not keep track of who are children of a
> commit.
Hmmm... how does the --topo-order logic ensure that parents are shown
after all of their children? Essentially I want that logic applied to
the boundary parent commits as well as the requested commits.
The other thing is that if git-rev-list can actually list those
boundary parents, complete with the whole commit message if --header
is given, then that will save gitk from having to do a git-cat-file to
get that information.
Paul.
^ permalink raw reply
* Re: [PATCH] xdiff: Show function names in hunk headers.
From: Junio C Hamano @ 2006-03-28 5:54 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <11435126113456-git-send-email-mdw@distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> The function names are parsed by a particularly stupid algorithm at the
> moment: it just tries to find a line in the `old' file, from before the
> start of the hunk, whose first character looks plausible. Still, it's
> most definitely a start.
> + (isalpha((unsigned char)*rec) || /* identifier? */
> + *rec == '_' || /* also identifier? */
> + *rec == '(' || /* lisp defun? */
> + *rec == '#')) { /* #define? */
GNU diff -p does "^[[:alpha:]$_]"; personally I think any line
that does not begin with a whitespace is good enough. In either
way, your patch is good. Thanks.
^ permalink raw reply
* Re: Gitk strangeness..
From: Junio C Hamano @ 2006-03-28 5:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17448.48143.764989.649462@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Would it be possible to put the '-' in only for the last child that
> has that parent?
Not trivially. We do not keep track of who are children of a
commit.
^ permalink raw reply
* Re: Gitk strangeness..
From: Paul Mackerras @ 2006-03-28 4:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr74nmg7e.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> I might be off the mark, but are you thinking about something
> like the attached patch?
The thing is that I need to know when I have seen the last child of
the boundary parent, because I only want to draw the open-circle
commit after I have drawn all its children.
Would it be possible to put the '-' in only for the last child that
has that parent?
Paul.
^ permalink raw reply
* Re: [PATCH] Add ALL_LDFLAGS to the git target.
From: Jason Riedy @ 2006-03-28 3:11 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wwnnyvt.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- I wonder what the dependency is, since ALL_LDFLAGS is not
- modified on AIX, [...]
Specifically, -lcrypto. Mine is in a funny place, so I need
LDFLAGS passed in.
- > Once it builds, only one test "fails" on AIX 5.1 with
- > 1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some
- > odd tool problem in the tester + my setup and not a real bug.
-
- Curious and would appreciate more details.
I just found it. The progress meter stuff in pack-objects
splats all over the output. So trash/client/log.txt is
completely mangled. Everything functions correctly, but
the textual output is garbage. If I set progress to 0 in
pack-objects.c, everthing's happy.
There's no way to pass -q through fetch-pack to upload-pack...
Gee, look, a comment that says "Yeah, yeah, fixme." I have
no real desire to add an args argument and propagate that
change through all the connect routines. An alternative is
to add a "quiet" command to the protocol. Another would be
to dup all three file descriptors. yech. Preference?
(I haven't updated git in a while on this platform.
Recompiling and testing takes a while on a 375 MHz Power3.)
Jason
^ permalink raw reply
* Re: Gitk strangeness..
From: Linus Torvalds @ 2006-03-28 2:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <17448.40941.256361.866229@cargo.ozlabs.ibm.com>
On Tue, 28 Mar 2006, Paul Mackerras wrote:
>
> The other option would be to make git-rev-list list the open-circle
> commits explicitly, with an indication that they are not in the
> requested set but are parents of commits in the requested set.
Just as an indication of _how_ simple that is, here's a stupid patch.
It just puts a "-" after a parent that isn't going to be shown.
Play with it (and it probably needs a new flag to enable it, since doing
it unconditionally like this will break old versions of gitk and
probably anything else that uses the "--parent" flag).
Linus
----
diff --git a/rev-list.c b/rev-list.c
index 441c437..822a740 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -60,6 +60,8 @@
if (o->flags & TMP_MARK)
continue;
printf(" %s", sha1_to_hex(o->sha1));
+ if (o->flags & UNINTERESTING)
+ putchar('-');
o->flags |= TMP_MARK;
}
/* TMP_MARK is a general purpose flag that can
^ permalink raw reply related
* Re: Gitk strangeness..
From: Junio C Hamano @ 2006-03-28 2:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17448.40941.256361.866229@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> The other option would be to make git-rev-list list the open-circle
> commits explicitly, with an indication that they are not in the
> requested set but are parents of commits in the requested set.
I might be off the mark, but are you thinking about something
like the attached patch?
> Do you think that having the open-circle commits in the graph is
> useful?
Of course.
-- >8 --
rev-list: --parents-with-boundary
The new flag acts like --parents, but uninteresting parents are
marked by prefied '-' sign.
$ git-rev-list --parents-with-boundary HEAD^^..HEAD
acb7257... 9c48666...
9c48666... -dff86e2..
---
diff --git a/rev-list.c b/rev-list.c
index 441c437..58fc449 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -39,6 +39,8 @@
static int bisect_list = 0;
static int verbose_header = 0;
static int abbrev = DEFAULT_ABBREV;
+#define SHOW_PARENTS 1
+#define SHOW_PARENTS_BOUNDARY 2
static int show_parents = 0;
static int show_timestamp = 0;
static int hdr_termination = 0;
@@ -59,7 +61,11 @@
parents = parents->next;
if (o->flags & TMP_MARK)
continue;
- printf(" %s", sha1_to_hex(o->sha1));
+ if (show_parents == SHOW_PARENTS_BOUNDARY &&
+ o->flags & UNINTERESTING)
+ printf(" -%s", sha1_to_hex(o->sha1));
+ else
+ printf(" %s", sha1_to_hex(o->sha1));
o->flags |= TMP_MARK;
}
/* TMP_MARK is a general purpose flag that can
@@ -337,7 +343,11 @@
continue;
}
if (!strcmp(arg, "--parents")) {
- show_parents = 1;
+ show_parents = SHOW_PARENTS;
+ continue;
+ }
+ if (!strcmp(arg, "--parents-with-boundary")) {
+ show_parents = SHOW_PARENTS_BOUNDARY;
continue;
}
if (!strcmp(arg, "--timestamp")) {
^ permalink raw reply related
* Re: Gitk strangeness..
From: Linus Torvalds @ 2006-03-28 2:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <17448.40941.256361.866229@cargo.ozlabs.ibm.com>
On Tue, 28 Mar 2006, Paul Mackerras wrote:
>
> I think the best thing to do is to change git-rev-list. One
> possibility would be to add an option to make git-rev-list omit
> parents that are not in the requested set, which would mean that gitk
> would not draw the open-circle commits any more.
I love the open circles. I often want to know what the previous commit
was. For example, I use gitk mainly for "gitk ORIG_HEAD..", and then I see
the thing that the newly merged stuff was based on (ie was it a major
release, or some random point).
> The other option would be to make git-rev-list list the open-circle
> commits explicitly, with an indication that they are not in the
> requested set but are parents of commits in the requested set.
Hmm. That shouldn't be hard to do, but what would be syntax be?
Linus
^ permalink raw reply
* Re: Gitk strangeness..
From: Paul Mackerras @ 2006-03-28 2:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0603271802030.15714@g5.osdl.org>
Linus Torvalds writes:
> Paul, do this on the current git tree:
>
> gitk b0a3de42..dff86e28
>
> and tell me it doesn't look horrid.
Wow! That's spectacular! :)
> Maybe it's not a new thing, and it's just that the recent pattern of
> merges in the git tree makes any version of gitk do horrible things.
A large part of it is that I took out the stuff where gitk used to
reorder the commits it got from git-rev-list. One of the side-effects
of doing the reordering was that for commits which aren't listed in
the git-rev-list output (i.e. which are drawn with open circles), gitk
was able to draw them immediately after their last child. Now gitk
doesn't discover that they aren't listed until it has drawn all the
commits that are listed, which means we can get a whole pile of
open-circle commits at the bottom of the graph.
I think the best thing to do is to change git-rev-list. One
possibility would be to add an option to make git-rev-list omit
parents that are not in the requested set, which would mean that gitk
would not draw the open-circle commits any more.
The other option would be to make git-rev-list list the open-circle
commits explicitly, with an indication that they are not in the
requested set but are parents of commits in the requested set.
Or I can put the logic back into gitk. I'd rather do it in
git-rev-list though since it will be faster that way.
Do you think that having the open-circle commits in the graph is
useful?
Paul.
^ permalink raw reply
* [PATCH] xdiff: Show function names in hunk headers.
From: Mark Wooding @ 2006-03-28 2:23 UTC (permalink / raw)
To: git; +Cc: Mark Wooding
The speed of the built-in diff generator is nice; but the function names
shown by `diff -p' are /really/ nice. And I hate having to choose. So,
we hack xdiff to find the function names and print them.
xdiff has grown a flag to say whether to dig up the function names. The
builtin_diff function passes this flag unconditionally. I suppose it
could parse GIT_DIFF_OPTS, but it doesn't at the moment. I've also
reintroduced the `function name' into the test suite, from which it was
removed in commit 3ce8f089.
The function names are parsed by a particularly stupid algorithm at the
moment: it just tries to find a line in the `old' file, from before the
start of the hunk, whose first character looks plausible. Still, it's
most definitely a start.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
diff.c | 1 +
t/t4001-diff-rename.sh | 2 +-
xdiff/xdiff.h | 3 +++
xdiff/xemit.c | 41 ++++++++++++++++++++++++++++++++++++++++-
xdiff/xinclude.h | 1 +
xdiff/xutils.c | 15 ++++++++++++---
xdiff/xutils.h | 3 ++-
7 files changed, 60 insertions(+), 6 deletions(-)
746418a20769c003886d7f4bbec6563af7aabd4b
diff --git a/diff.c b/diff.c
index 5eae094..8b37477 100644
--- a/diff.c
+++ b/diff.c
@@ -267,6 +267,7 @@ static void builtin_diff(const char *nam
ecbdata.label_path = lbl;
xpp.flags = XDF_NEED_MINIMAL;
xecfg.ctxlen = 3;
+ xecfg.flags = XDL_EMIT_FUNCNAMES;
if (!diffopts)
;
else if (!strncmp(diffopts, "--unified=", 10))
diff --git a/t/t4001-diff-rename.sh b/t/t4001-diff-rename.sh
index 08c1131..2e3c20d 100755
--- a/t/t4001-diff-rename.sh
+++ b/t/t4001-diff-rename.sh
@@ -49,7 +49,7 @@ rename from path0
rename to path1
--- a/path0
+++ b/path1
-@@ -8,7 +8,7 @@
+@@ -8,7 +8,7 @@ Line 7
Line 8
Line 9
Line 10
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 71cb939..2540e8a 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -35,6 +35,8 @@ #define XDL_PATCH_REVERSE '+'
#define XDL_PATCH_MODEMASK ((1 << 8) - 1)
#define XDL_PATCH_IGNOREBSPACE (1 << 8)
+#define XDL_EMIT_FUNCNAMES (1 << 0)
+
#define XDL_MMB_READONLY (1 << 0)
#define XDL_MMF_ATOMIC (1 << 0)
@@ -65,6 +67,7 @@ typedef struct s_xdemitcb {
typedef struct s_xdemitconf {
long ctxlen;
+ unsigned long flags;
} xdemitconf_t;
typedef struct s_bdiffparam {
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 2e5d54c..ad5bfb1 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -69,10 +69,43 @@ static xdchange_t *xdl_get_hunk(xdchange
}
+static void xdl_find_func(xdfile_t *xf, long i, char *buf, long sz, long *ll) {
+
+ /*
+ * Be quite stupid about this for now. Find a line in the old file
+ * before the start of the hunk (and context) which starts with a
+ * plausible character.
+ */
+
+ const char *rec;
+ long len;
+
+ *ll = 0;
+ while (i-- > 0) {
+ len = xdl_get_rec(xf, i, &rec);
+ if (len > 0 &&
+ (isalpha((unsigned char)*rec) || /* identifier? */
+ *rec == '_' || /* also identifier? */
+ *rec == '(' || /* lisp defun? */
+ *rec == '#')) { /* #define? */
+ if (len > sz)
+ len = sz;
+ if (len && rec[len - 1] == '\n')
+ len--;
+ memcpy(buf, rec, len);
+ *ll = len;
+ return;
+ }
+ }
+}
+
+
int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
xdemitconf_t const *xecfg) {
long s1, s2, e1, e2, lctx;
xdchange_t *xch, *xche;
+ char funcbuf[40];
+ long funclen = 0;
for (xch = xche = xscr; xch; xch = xche->next) {
xche = xdl_get_hunk(xch, xecfg);
@@ -90,7 +123,13 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange
/*
* Emit current hunk header.
*/
- if (xdl_emit_hunk_hdr(s1 + 1, e1 - s1, s2 + 1, e2 - s2, ecb) < 0)
+
+ if (xecfg->flags & XDL_EMIT_FUNCNAMES) {
+ xdl_find_func(&xe->xdf1, s1, funcbuf,
+ sizeof(funcbuf), &funclen);
+ }
+ if (xdl_emit_hunk_hdr(s1 + 1, e1 - s1, s2 + 1, e2 - s2,
+ funcbuf, funclen, ecb) < 0)
return -1;
/*
diff --git a/xdiff/xinclude.h b/xdiff/xinclude.h
index 9490fc5..04a9da8 100644
--- a/xdiff/xinclude.h
+++ b/xdiff/xinclude.h
@@ -23,6 +23,7 @@
#if !defined(XINCLUDE_H)
#define XINCLUDE_H
+#include <ctype.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
diff --git a/xdiff/xutils.c b/xdiff/xutils.c
index 8221806..afaada1 100644
--- a/xdiff/xutils.c
+++ b/xdiff/xutils.c
@@ -235,7 +235,8 @@ long xdl_atol(char const *str, char cons
}
-int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2, xdemitcb_t *ecb) {
+int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2,
+ const char *func, long funclen, xdemitcb_t *ecb) {
int nb = 0;
mmbuffer_t mb;
char buf[128];
@@ -264,8 +265,16 @@ int xdl_emit_hunk_hdr(long s1, long c1,
nb += xdl_num_out(buf + nb, c2);
}
- memcpy(buf + nb, " @@\n", 4);
- nb += 4;
+ memcpy(buf + nb, " @@", 3);
+ nb += 3;
+ if (func && funclen) {
+ buf[nb++] = ' ';
+ if (funclen > sizeof(buf) - nb - 1)
+ funclen = sizeof(buf) - nb - 1;
+ memcpy(buf + nb, func, funclen);
+ nb += funclen;
+ }
+ buf[nb++] = '\n';
mb.ptr = buf;
mb.size = nb;
diff --git a/xdiff/xutils.h b/xdiff/xutils.h
index 428a4bb..55b0d39 100644
--- a/xdiff/xutils.h
+++ b/xdiff/xutils.h
@@ -36,7 +36,8 @@ unsigned long xdl_hash_record(char const
unsigned int xdl_hashbits(unsigned int size);
int xdl_num_out(char *out, long val);
long xdl_atol(char const *str, char const **next);
-int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2, xdemitcb_t *ecb);
+int xdl_emit_hunk_hdr(long s1, long c1, long s2, long c2,
+ const char *func, long funclen, xdemitcb_t *ecb);
--
1.3.0.rc1.g7464
^ permalink raw reply related
* Re: Gitk strangeness..
From: Junio C Hamano @ 2006-03-28 2:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603271802030.15714@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Maybe it's not a new thing, and it's just that the recent pattern of
> merges in the git tree makes any version of gitk do horrible things.
It is both, but new gitk plays a major part of it.
There are too wide horizontal lines when many merges are
involved. My "next" branch from yesterday (which is essentially
what my "master" branch today) was somewhat more pleasant to
read with older gitk, but only somewhat.
^ permalink raw reply
* Gitk strangeness..
From: Linus Torvalds @ 2006-03-28 2:05 UTC (permalink / raw)
To: Junio C Hamano, Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <7v64lzo1j7.fsf@assigned-by-dhcp.cox.net>
On Mon, 27 Mar 2006, Junio C Hamano wrote:
>
> GIT 1.3.0-rc1 is pushed out and will be mirrored out soon.
I did
gitk ORIG_HEAD..
with this, and the end result looks horrible. I think it's the new gitk
that does it.
Paul, do this on the current git tree:
gitk b0a3de42..dff86e28
and tell me it doesn't look horrid.
Maybe it's not a new thing, and it's just that the recent pattern of
merges in the git tree makes any version of gitk do horrible things.
Linus
^ permalink raw reply
* Re: [PATCH] Add ALL_LDFLAGS to the git target.
From: Junio C Hamano @ 2006-03-28 1:25 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <13226.1143508524@lotus.CS.Berkeley.EDU>
Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
> For some reason, I need ALL_LDFLAGS in the git target only on
> AIX.
I wonder what the dependency is, since ALL_LDFLAGS is not
modified on AIX, but you are right. That is the only binary
that does not link with ALL_LDFLAGS which can include whatever
user passes via LDFLAGS.
> Once it builds, only one test "fails" on AIX 5.1 with
> 1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some
> odd tool problem in the tester + my setup and not a real bug.
Curious and would appreciate more details.
^ permalink raw reply
* [PATCH] Add ALL_LDFLAGS to the git target.
From: Jason Riedy @ 2006-03-28 1:15 UTC (permalink / raw)
To: git
In-Reply-To: <7v64lzo1j7.fsf@assigned-by-dhcp.cox.net>
For some reason, I need ALL_LDFLAGS in the git target only on
AIX. Once it builds, only one test "fails" on AIX 5.1 with
1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some
odd tool problem in the tester + my setup and not a real bug.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
diff --git a/Makefile b/Makefile
index 4edb383..d945546 100644
--- a/Makefile
+++ b/Makefile
@@ -455,7 +455,8 @@ strip: $(PROGRAMS) git$X
git$X: git.c common-cmds.h $(LIB_FILE)
$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
- $(ALL_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE) $(LIBS)
+ $(ALL_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE) \
+ $(ALL_LDFLAGS) $(LIBS)
common-cmds.h: Documentation/git-*.txt
./generate-cmdlist.sh > $@
^ permalink raw reply related
* What's in git.git
From: Junio C Hamano @ 2006-03-28 0:28 UTC (permalink / raw)
To: git
GIT 1.3.0-rc1 is pushed out and will be mirrored out soon.
All of the things that were not in the "master" branch were
either cooked long enough in "next" without causing problems
(e.g. insanely fast rename detector or true built-in diff) or
isolated in a specific subsystem (e.g. tar-tree and svnimport).
So I am clearing the deck to prepare for a 1.3.0. Remaining
wrinkles, if any, will be ironed out in the "master" branch.
------------
Changes since the last announcement:
- updates around git-clone:
. --use-separate-remote
. --reference <repo>
. fetch,parse-remote,fmt-merge-msg: refs/remotes/* support (Eric Wong)
. sha1_name() understands refs/remotes/$foo/HEAD
- sha1_name safety and core.warnambiguousrefs
- git-merge knows some strategies want to skip trivial merges
- insanely fast rename detection (Linus and me)
- tar-tree updates (Rene Scharfe)
- send-email updates (Eric Wong)
- truly built-in diff (Linus with Davide)
- ls-{files,tree} --abbrev (Eric Wong)
- git-svnimport: if a limit is specified, respect it (Anand Kumria)
- documentation (J. Bruce Fields)
- build fix (Johannes Schindelin)
- git-ls-files --others --directory --no-empty-directory (Petr Baudis)
- gitk updates (Martin Mares, Paul Mackerras)
- GIT 1.3.0 rc1 (me)
Currently "next" and "pu" are empty.
^ permalink raw reply
* Re: Problem with git bisect between 2.6.15 and 2.6.16
From: Tony Luck @ 2006-03-28 0:22 UTC (permalink / raw)
To: Greg Lee; +Cc: sean, git
In-Reply-To: <0e7e01c651fc$e30a2860$a100a8c0@casabyte.com>
> No, the problem was fixed in 2.6.16 and I'm trying to figure out what fixed it so that I
> can back-port the fix into a previous kernel version, so 2.6.16 is good and 2.6.15 is bad.
You'll need to invert "good" and bad" for this. I.e. mark 2.6.15 as
good, 2.6.16 as bad, and
then as you test mark kernels with the bug as good, and ones without
as bad. Try not to go
insane while working in this inverted parallel universe :-)
-Tony
^ permalink raw reply
* Re: Selecting the minor revs
From: sean @ 2006-03-28 0:18 UTC (permalink / raw)
To: Greg Lee; +Cc: git
In-Reply-To: <0e7d01c651fb$fa11ceb0$a100a8c0@casabyte.com>
On Mon, 27 Mar 2006 19:10:09 -0500
"Greg Lee" <glee@swspec.com> wrote:
> > If you're interested in the stable-series releases of the
> > kernel, unfortunately they're not in the git repository.
>
> As I feared ... I'm curious, why?
Because the stable-series is maintained by people other than Linus.
They may have their own git tree, i'm not sure. Even if they don't,
you could create a stable-series branch and import the patches
into your git repo if it was something you needed often.
Sean
^ 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