{"thread":{"id":"3740","subject":"What's in git.git","startedAt":"2006-03-28T00:28:44Z","lastAt":"2006-03-31T06:27:34Z","messageCount":33,"participants":["Junio C Hamano","Jason Riedy","Linus Torvalds","Paul Mackerras","Mark Wooding","Petr Baudis","Johannes Schindelin","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"18048","messageId":"7v64lzo1j7.fsf@assigned-by-dhcp.cox.net","threadId":"3740","inReplyTo":null,"subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-28T00:28:44Z","receivedAt":"2006-03-28T00:28:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"GIT 1.3.0-rc1 is pushed out and will be mirrored out soon.\n\nAll of the things that were not in the \"master\" branch were\neither cooked long enough in \"next\" without causing problems\n(e.g. insanely fast rename detector or true built-in diff) or\nisolated in a specific subsystem (e.g. tar-tree and svnimport).\n\nSo I am clearing the deck to prepare for a 1.3.0. Remaining\nwrinkles, if any, will be ironed out in the \"master\" branch.\n\n------------\nChanges since the last announcement:\n\n - updates around git-clone:\n . --use-separate-remote\n . --reference \n . fetch,parse-remote,fmt-merge-msg: refs/remotes/* support (Eric Wong)\n . sha1_name() understands refs/remotes/$foo/HEAD\n\n - sha1_name safety and core.warnambiguousrefs\n\n - git-merge knows some strategies want to skip trivial merges\n\n - insanely fast rename detection (Linus and me)\n\n - tar-tree updates (Rene Scharfe)\n\n - send-email updates (Eric Wong)\n\n - truly built-in diff (Linus with Davide)\n\n - ls-{files,tree} --abbrev (Eric Wong)\n\n - git-svnimport: if a limit is specified, respect it (Anand Kumria)\n\n - documentation (J. Bruce Fields)\n\n - build fix (Johannes Schindelin)\n\n - git-ls-files --others --directory --no-empty-directory (Petr Baudis)\n\n - gitk updates (Martin Mares, Paul Mackerras)\n\n - GIT 1.3.0 rc1 (me)\n\nCurrently \"next\" and \"pu\" are empty.\n"},{"id":"18049","messageId":"13226.1143508524@lotus.CS.Berkeley.EDU","threadId":"3740","inReplyTo":"7v64lzo1j7.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Add ALL_LDFLAGS to the git target.","fromName":"Jason Riedy","fromEmail":"ejr@eecs.berkeley.edu","sentAt":"2006-03-28T01:15:24Z","receivedAt":"2006-03-28T01:15:24Z","isPatch":true,"sender":{"key":"ejr@eecs.berkeley.edu","avatar":"https://gravatar.com/avatar/547fa56f887cab01599edab4e9f813c949c1269e02714f20e0496c56185d9837?d=mp&s=160"},"body":"For some reason, I need ALL_LDFLAGS in the git target only on\nAIX. Once it builds, only one test \"fails\" on AIX 5.1 with \n1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some\nodd tool problem in the tester + my setup and not a real bug.\n\nSigned-off-by: Jason Riedy \n\ndiff --git a/Makefile b/Makefile\nindex 4edb383..d945546 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -455,7 +455,8 @@ strip: $(PROGRAMS) git$X\n \n git$X: git.c common-cmds.h $(LIB_FILE)\n \t$(CC) -DGIT_VERSION='\"$(GIT_VERSION)\"' \\\n-\t\t$(ALL_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE) $(LIBS)\n+\t\t$(ALL_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE) \\\n+\t\t$(ALL_LDFLAGS) $(LIBS)\n \n common-cmds.h: Documentation/git-*.txt\n \t./generate-cmdlist.sh > $@\n"},{"id":"18050","messageId":"7v1wwnnyvt.fsf@assigned-by-dhcp.cox.net","threadId":"3740","inReplyTo":"13226.1143508524@lotus.CS.Berkeley.EDU","subject":"Re: [PATCH] Add ALL_LDFLAGS to the git target.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-28T01:25:58Z","receivedAt":"2006-03-28T01:25:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jason Riedy writes:\n\n> For some reason, I need ALL_LDFLAGS in the git target only on\n> AIX.\n\nI wonder what the dependency is, since ALL_LDFLAGS is not\nmodified on AIX, but you are right. That is the only binary\nthat does not link with ALL_LDFLAGS which can include whatever\nuser passes via LDFLAGS.\n\n> Once it builds, only one test \"fails\" on AIX 5.1 with \n> 1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some\n> odd tool problem in the tester + my setup and not a real bug.\n\nCurious and would appreciate more details.\n"},{"id":"18051","messageId":"Pine.LNX.4.64.0603271802030.15714@g5.osdl.org","threadId":"3740","inReplyTo":"7v64lzo1j7.fsf@assigned-by-dhcp.cox.net","subject":"Gitk strangeness..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-28T02:05:49Z","receivedAt":"2006-03-28T02:05:49Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 27 Mar 2006, Junio C Hamano wrote:\n>\n> GIT 1.3.0-rc1 is pushed out and will be mirrored out soon.\n\nI did \n\n\tgitk ORIG_HEAD..\n\nwith this, and the end result looks horrible. I think it's the new gitk \nthat does it.\n\nPaul, do this on the current git tree:\n\n\tgitk b0a3de42..dff86e28\n\nand tell me it doesn't look horrid.\n\nMaybe it's not a new thing, and it's just that the recent pattern of \nmerges in the git tree makes any version of gitk do horrible things.\n\n\t\tLinus\n"},{"id":"18052","messageId":"7vwtefmi6g.fsf@assigned-by-dhcp.cox.net","threadId":"3740","inReplyTo":"Pine.LNX.4.64.0603271802030.15714@g5.osdl.org","subject":"Re: Gitk strangeness..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-28T02:12:07Z","receivedAt":"2006-03-28T02:12:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Maybe it's not a new thing, and it's just that the recent pattern of \n> merges in the git tree makes any version of gitk do horrible things.\n\nIt is both, but new gitk plays a major part of it.\n\nThere are too wide horizontal lines when many merges are\ninvolved. My \"next\" branch from yesterday (which is essentially\nwhat my \"master\" branch today) was somewhat more pleasant to\nread with older gitk, but only somewhat.\n"},{"id":"18054","messageId":"17448.40941.256361.866229@cargo.ozlabs.ibm.com","threadId":"3740","inReplyTo":"Pine.LNX.4.64.0603271802030.15714@g5.osdl.org","subject":"Re: Gitk strangeness..","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-03-28T02:31:09Z","receivedAt":"2006-03-28T02:31:09Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Linus Torvalds writes:\n\n> Paul, do this on the current git tree:\n> \n> \tgitk b0a3de42..dff86e28\n> \n> and tell me it doesn't look horrid.\n\nWow! That's spectacular! :)\n\n> Maybe it's not a new thing, and it's just that the recent pattern of \n> merges in the git tree makes any version of gitk do horrible things.\n\nA large part of it is that I took out the stuff where gitk used to\nreorder the commits it got from git-rev-list. One of the side-effects\nof doing the reordering was that for commits which aren't listed in\nthe git-rev-list output (i.e. which are drawn with open circles), gitk\nwas able to draw them immediately after their last child. Now gitk\ndoesn't discover that they aren't listed until it has drawn all the\ncommits that are listed, which means we can get a whole pile of\nopen-circle commits at the bottom of the graph.\n\nI think the best thing to do is to change git-rev-list. One\npossibility would be to add an option to make git-rev-list omit\nparents that are not in the requested set, which would mean that gitk\nwould not draw the open-circle commits any more.\n\nThe other option would be to make git-rev-list list the open-circle\ncommits explicitly, with an indication that they are not in the\nrequested set but are parents of commits in the requested set.\n\nOr I can put the logic back into gitk. I'd rather do it in\ngit-rev-list though since it will be faster that way.\n\nDo you think that having the open-circle commits in the graph is\nuseful?\n\nPaul.\n"},{"id":"18055","messageId":"Pine.LNX.4.64.0603271848190.15714@g5.osdl.org","threadId":"3740","inReplyTo":"17448.40941.256361.866229@cargo.ozlabs.ibm.com","subject":"Re: Gitk strangeness..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-28T02:52:58Z","receivedAt":"2006-03-28T02:52:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Mar 2006, Paul Mackerras wrote:\n> \n> I think the best thing to do is to change git-rev-list. One\n> possibility would be to add an option to make git-rev-list omit\n> parents that are not in the requested set, which would mean that gitk\n> would not draw the open-circle commits any more.\n\nI love the open circles. I often want to know what the previous commit \nwas. For example, I use gitk mainly for \"gitk ORIG_HEAD..\", and then I see \nthe thing that the newly merged stuff was based on (ie was it a major \nrelease, or some random point).\n\n> The other option would be to make git-rev-list list the open-circle\n> commits explicitly, with an indication that they are not in the\n> requested set but are parents of commits in the requested set.\n\nHmm. That shouldn't be hard to do, but what would be syntax be?\n\n\t\tLinus\n"},{"id":"18056","messageId":"7vr74nmg7e.fsf@assigned-by-dhcp.cox.net","threadId":"3740","inReplyTo":"17448.40941.256361.866229@cargo.ozlabs.ibm.com","subject":"Re: Gitk strangeness..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-28T02:54:45Z","receivedAt":"2006-03-28T02:54:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> The other option would be to make git-rev-list list the open-circle\n> commits explicitly, with an indication that they are not in the\n> requested set but are parents of commits in the requested set.\n\nI might be off the mark, but are you thinking about something\nlike the attached patch?\n\n> Do you think that having the open-circle commits in the graph is\n> useful?\n\nOf course.\n\n-- >8 --\nrev-list: --parents-with-boundary\n\nThe new flag acts like --parents, but uninteresting parents are\nmarked by prefied '-' sign.\n\n $ git-rev-list --parents-with-boundary HEAD^^..HEAD\n acb7257... 9c48666...\n 9c48666... -dff86e2..\n\n---\ndiff --git a/rev-list.c b/rev-list.c\nindex 441c437..58fc449 100644\n--- a/rev-list.c\n+++ b/rev-list.c\n@@ -39,6 +39,8 @@\n static int bisect_list = 0;\n static int verbose_header = 0;\n static int abbrev = DEFAULT_ABBREV;\n+#define SHOW_PARENTS 1\n+#define SHOW_PARENTS_BOUNDARY 2\n static int show_parents = 0;\n static int show_timestamp = 0;\n static int hdr_termination = 0;\n@@ -59,7 +61,11 @@\n \t\t\tparents = parents->next;\n \t\t\tif (o->flags & TMP_MARK)\n \t\t\t\tcontinue;\n-\t\t\tprintf(\" %s\", sha1_to_hex(o->sha1));\n+\t\t\tif (show_parents == SHOW_PARENTS_BOUNDARY &&\n+\t\t\t o->flags & UNINTERESTING)\n+\t\t\t\tprintf(\" -%s\", sha1_to_hex(o->sha1));\n+\t\t\telse\n+\t\t\t\tprintf(\" %s\", sha1_to_hex(o->sha1));\n \t\t\to->flags |= TMP_MARK;\n \t\t}\n \t\t/* TMP_MARK is a general purpose flag that can\n@@ -337,7 +343,11 @@\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strcmp(arg, \"--parents\")) {\n-\t\t\tshow_parents = 1;\n+\t\t\tshow_parents = SHOW_PARENTS;\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (!strcmp(arg, \"--parents-with-boundary\")) {\n+\t\t\tshow_parents = SHOW_PARENTS_BOUNDARY;\n \t\t\tcontinue;\n \t\t}\n \t\tif (!strcmp(arg, \"--timestamp\")) {\n"},{"id":"18057","messageId":"Pine.LNX.4.64.0603271856070.15714@g5.osdl.org","threadId":"3740","inReplyTo":"17448.40941.256361.866229@cargo.ozlabs.ibm.com","subject":"Re: Gitk strangeness..","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-28T02:57:42Z","receivedAt":"2006-03-28T02:57:42Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Mar 2006, Paul Mackerras wrote:\n>\n> The other option would be to make git-rev-list list the open-circle\n> commits explicitly, with an indication that they are not in the\n> requested set but are parents of commits in the requested set.\n\nJust as an indication of _how_ simple that is, here's a stupid patch.\n\nIt just puts a \"-\" after a parent that isn't going to be shown.\n\nPlay with it (and it probably needs a new flag to enable it, since doing \nit unconditionally like this will break old versions of gitk and \nprobably anything else that uses the \"--parent\" flag).\n\n\t\tLinus\n\n----\ndiff --git a/rev-list.c b/rev-list.c\nindex 441c437..822a740 100644\n--- a/rev-list.c\n+++ b/rev-list.c\n@@ -60,6 +60,8 @@\n \t\t\tif (o->flags & TMP_MARK)\n \t\t\t\tcontinue;\n \t\t\tprintf(\" %s\", sha1_to_hex(o->sha1));\n+\t\t\tif (o->flags & UNINTERESTING)\n+\t\t\t\tputchar('-');\n \t\t\to->flags |= TMP_MARK;\n \t\t}\n \t\t/* TMP_MARK is a general purpose flag that can\n"},{"id":"18058","messageId":"13360.1143515503@lotus.CS.Berkeley.EDU","threadId":"3740","inReplyTo":"7v1wwnnyvt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add ALL_LDFLAGS to the git target.","fromName":"Jason Riedy","fromEmail":"ejr@eecs.berkeley.edu","sentAt":"2006-03-28T03:11:43Z","receivedAt":"2006-03-28T03:11:43Z","isPatch":true,"sender":{"key":"ejr@eecs.berkeley.edu","avatar":"https://gravatar.com/avatar/547fa56f887cab01599edab4e9f813c949c1269e02714f20e0496c56185d9837?d=mp&s=160"},"body":"And Junio C Hamano writes:\n - I wonder what the dependency is, since ALL_LDFLAGS is not\n - modified on AIX, [...]\n\nSpecifically, -lcrypto. Mine is in a funny place, so I need\nLDFLAGS passed in.\n\n - > Once it builds, only one test \"fails\" on AIX 5.1 with \n - > 1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some\n - > odd tool problem in the tester + my setup and not a real bug.\n - \n - Curious and would appreciate more details.\n\nI just found it. The progress meter stuff in pack-objects\nsplats all over the output. So trash/client/log.txt is\ncompletely mangled. Everything functions correctly, but\nthe textual output is garbage. If I set progress to 0 in \npack-objects.c, everthing's happy.\n\nThere's no way to pass -q through fetch-pack to upload-pack...\nGee, look, a comment that says \"Yeah, yeah, fixme.\" I have\nno real desire to add an args argument and propagate that\nchange through all the connect routines. An alternative is\nto add a \"quiet\" command to the protocol. Another would be \nto dup all three file descriptors. yech. Preference?\n\n(I haven't updated git in a while on this platform. \nRecompiling and testing takes a while on a 375 MHz Power3.)\n\nJason\n"},{"id":"18059","messageId":"17448.48143.764989.649462@cargo.ozlabs.ibm.com","threadId":"3740","inReplyTo":"7vr74nmg7e.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk strangeness..","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-03-28T04:31:11Z","receivedAt":"2006-03-28T04:31:11Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Junio C Hamano writes:\n\n> I might be off the mark, but are you thinking about something\n> like the attached patch?\n\nThe thing is that I need to know when I have seen the last child of\nthe boundary parent, because I only want to draw the open-circle\ncommit after I have drawn all its children.\n\nWould it be possible to put the '-' in only for the last child that\nhas that parent?\n\nPaul.\n"},{"id":"18060","messageId":"7vmzfbm8m0.fsf@assigned-by-dhcp.cox.net","threadId":"3740","inReplyTo":"17448.48143.764989.649462@cargo.ozlabs.ibm.com","subject":"Re: Gitk strangeness..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-28T05:38:47Z","receivedAt":"2006-03-28T05:38:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> Would it be possible to put the '-' in only for the last child that\n> has that parent?\n\nNot trivially. We do not keep track of who are children of a\ncommit.\n"},{"id":"18062","messageId":"17448.54558.865097.519248@cargo.ozlabs.ibm.com","threadId":"3740","inReplyTo":"7vmzfbm8m0.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk strangeness..","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-03-28T06:18:06Z","receivedAt":"2006-03-28T06:18:06Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"> > Would it be possible to put the '-' in only for the last child that\n> > has that parent?\n> \n> Not trivially. We do not keep track of who are children of a\n> commit.\n\nHmmm... how does the --topo-order logic ensure that parents are shown\nafter all of their children? Essentially I want that logic applied to\nthe boundary parent commits as well as the requested commits.\n\nThe other thing is that if git-rev-list can actually list those\nboundary parents, complete with the whole commit message if --header\nis given, then that will save gitk from having to do a git-cat-file to\nget that information.\n\nPaul.\n"},{"id":"18063","messageId":"7vu09jks1u.fsf@assigned-by-dhcp.cox.net","threadId":"3740","inReplyTo":"13360.1143515503@lotus.CS.Berkeley.EDU","subject":"Re: [PATCH] Add ALL_LDFLAGS to the git target.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-28T06:21:49Z","receivedAt":"2006-03-28T06:21:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jason Riedy writes:\n\n> And Junio C Hamano writes:\n> - I wonder what the dependency is, since ALL_LDFLAGS is not\n> - modified on AIX, [...]\n>\n> Specifically, -lcrypto. Mine is in a funny place, so I need\n> LDFLAGS passed in.\n\nThanks. That is the right fix, then.\n\n> - > Once it builds, only one test \"fails\" on AIX 5.1 with \n> - > 1.3.0.rc1, t5500-fetch-pack.sh, but it looks like it's some\n> - > odd tool problem in the tester + my setup and not a real bug.\n> - \n> - Curious and would appreciate more details.\n>\n> I just found it. The progress meter stuff in pack-objects\n> splats all over the output. So trash/client/log.txt is\n> completely mangled. Everything functions correctly, but\n> the textual output is garbage. If I set progress to 0 in \n> pack-objects.c, everthing's happy.\n\nHmph. We do fprintf(stderr, \"blah\\r\") to draw them. The\nstandard says that \"standard error stream is not fully\nbuffered\", but I guess it does not necessarily mean it is\nunbuffered, so we probably need to fflush(3) there. Would\nsomething like this help?\n\n-- >8 --\ndiff --git a/fetch-clone.c b/fetch-clone.c\nindex da1b3ff..252e5ec 100644\n--- a/fetch-clone.c\n+++ b/fetch-clone.c\n@@ -230,6 +230,7 @@\n \t\t\t\t\ttotal >> 20,\n \t\t\t\t\t1000*((total >> 10) & 1023)>>10,\n \t\t\t\t\tavg_bytes / avg_time );\n+\t\t\t\tfflush(stderr);\n \t\t\t}\n \t\t}\n \t}\ndiff --git a/imap-send.c b/imap-send.c\nindex e33c78b..dcfa8d8 100644\n--- a/imap-send.c\n+++ b/imap-send.c\n@@ -1345,6 +1345,7 @@\n \twhile (1) {\n \t\tunsigned percent = n * 100 / total;\n \t\tfprintf( stderr, \"%4u%% (%d/%d) done\\r\", percent, n, total );\n+\t\tfflush(stderr);\n \t\tif (!split_msg( &all_msgs, &msg, &ofs ))\n \t\t\tbreak;\n \t\tr = imap_store_msg( ctx, &msg, &uid );\ndiff --git a/pack-objects.c b/pack-objects.c\nindex 49357c6..7c85348 100644\n--- a/pack-objects.c\n+++ b/pack-objects.c\n@@ -360,6 +360,7 @@\n \t\t\tif (progress_update || percent != last_percent) {\n \t\t\t\tfprintf(stderr, \"%4u%% (%u/%u) done\\r\",\n \t\t\t\t\tpercent, written, nr_result);\n+\t\t\t\tfflush(stderr);\n \t\t\t\tprogress_update = 0;\n \t\t\t\tlast_percent = percent;\n \t\t\t}\n@@ -570,6 +571,7 @@\n already_added:\n \tif (progress_update) {\n \t\tfprintf(stderr, \"Counting objects...%d\\r\", nr_objects);\n+\t\tfflush(stderr);\n \t\tprogress_update = 0;\n \t}\n \tif (exclude)\n@@ -912,6 +914,7 @@\n \t\t\tif (percent != last_percent || progress_update) {\n \t\t\t\tfprintf(stderr, \"%4u%% (%u/%u) done\\r\",\n \t\t\t\t\tpercent, processed, nr_result);\n+\t\t\t\tfflush(stderr);\n \t\t\t\tprogress_update = 0;\n \t\t\t\tlast_percent = percent;\n \t\t\t}\ndiff --git a/read-tree.c b/read-tree.c\nindex eaff444..6a2aa16 100644\n--- a/read-tree.c\n+++ b/read-tree.c\n@@ -325,6 +325,7 @@\n \t\t\t\t progress_update) {\n \t\t\t\t\tfprintf(stderr, \"%4u%% (%u/%u) done\\r\",\n \t\t\t\t\t\tpercent, cnt, total);\n+\t\t\t\t\tfflush(stderr);\n \t\t\t\t\tlast_percent = percent;\n \t\t\t\t}\n \t\t\t}\ndiff --git a/unpack-objects.c b/unpack-objects.c\nindex 815a1b3..8596f9b 100644\n--- a/unpack-objects.c\n+++ b/unpack-objects.c\n@@ -220,6 +220,7 @@\n \t\t\tlast_sec = now.tv_sec;\n \t\t\tlast_percent = percentage;\n \t\t\tfprintf(stderr, \"%4u%% (%u/%u) done\\r\", percentage, nr, total);\n+\t\t\tfflush(stderr);\n \t\t}\n \t}\n \tswitch (type) {\n"},{"id":"18064","messageId":"7vzmjbj9a1.fsf@assigned-by-dhcp.cox.net","threadId":"3740","inReplyTo":"17448.54558.865097.519248@cargo.ozlabs.ibm.com","subject":"Re: Gitk strangeness..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-28T07:52:38Z","receivedAt":"2006-03-28T07:52:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n>> Not trivially. We do not keep track of who are children of a\n>> commit.\n>\n> Hmmm... how does the --topo-order logic ensure that parents are shown\n> after all of their children? Essentially I want that logic applied to\n> the boundary parent commits as well as the requested commits.\n\nThe sort happens after we sift which commits are interesting and\nwhich are not, and uninteresting ones are not subject to\nsorting, so that is too late.\n\n> The other thing is that if git-rev-list can actually list those\n> boundary parents, complete with the whole commit message if --header\n> is given, then that will save gitk from having to do a git-cat-file to\n> get that information.\n\nHow about this alternative patch, then? It turned out to be\nquite convoluted as I feared.\n\nFor example, with this graph:\n\n C side\n /\n\tA---B---D master\n\nThis command\n\n\t$ git rev-list --boundary --header --parents side..master\n\nwould give:\n\n\tD B\n tree D^{tree}\n parent B\n ...\n \\0-B A\n tree B^{tree}\n parent A\n ...\n \\0\n\nThat is, it includes the UNINTERESING commits at the boundary,\nwhich are usually not shown, in its output, but their object\nnames are prefixed with a '-'.\n\n---\ndiff --git a/rev-list.c b/rev-list.c\nindex 441c437..a1f129b 100644\n--- a/rev-list.c\n+++ b/rev-list.c\n@@ -7,9 +7,9 @@\n #include \"diff.h\"\n #include \"revision.h\"\n \n-/* bits #0-4 in revision.h */\n+/* bits #0-5 in revision.h */\n \n-#define COUNTED\t\t(1u<<5)\n+#define COUNTED\t\t(1u<<6)\n \n static const char rev_list_usage[] =\n \"git-rev-list [OPTION] ... [ -- paths... ]\\n\"\n@@ -51,6 +51,8 @@\n \t\tprintf(\"%lu \", commit->date);\n \tif (commit_prefix[0])\n \t\tfputs(commit_prefix, stdout);\n+\tif (commit->object.flags & BOUNDARY)\n+\t\tputchar('-');\n \tfputs(sha1_to_hex(commit->object.sha1), stdout);\n \tif (show_parents) {\n \t\tstruct commit_list *parents = commit->parents;\ndiff --git a/revision.c b/revision.c\nindex d67718c..a9b8f9d 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -390,6 +390,21 @@\n \t}\n }\n \n+void debug_list(struct commit_list *l)\n+{\n+\tint i = 0;\n+\twhile (l) {\n+\t\tstruct commit *commit = l->item;\n+\t\tprintf(\"%d: %x %s\\n\",\n+\t\t i,\n+\t\t commit->object.flags,\n+\t\t sha1_to_hex(commit->object.sha1));\n+\t\tprintf(\" %s\\n\", commit->buffer);\n+\t\tl = l->next;\n+\t\ti++;\n+\t}\n+}\n+\n static void limit_list(struct rev_info *revs)\n {\n \tstruct commit_list *list = revs->commits;\n@@ -418,6 +433,27 @@\n \t\tif (revs->min_age != -1 && (commit->date > revs->min_age))\n \t\t\tcontinue;\n \t\tp = &commit_list_insert(commit, p)->next;\n+\t}\n+\tif (revs->boundary) {\n+\t\tlist = newlist;\n+\t\twhile (list) {\n+\t\t\tstruct commit *commit = list->item;\n+\t\t\tstruct object *obj = &commit->object;\n+\t\t\tstruct commit_list *parent = commit->parents;\n+\t\t\tif (obj->flags & (UNINTERESTING|BOUNDARY)) {\n+\t\t\t\tlist = list->next;\n+\t\t\t\tcontinue;\n+\t\t\t}\n+\t\t\twhile (parent) {\n+\t\t\t\tstruct commit *pcommit = parent->item;\n+\t\t\t\tparent = parent->next;\n+\t\t\t\tif (!(pcommit->object.flags & UNINTERESTING))\n+\t\t\t\t\tcontinue;\n+\t\t\t\tpcommit->object.flags |= BOUNDARY;\n+\t\t\t\tp = &commit_list_insert(pcommit, p)->next;\n+\t\t\t}\n+\t\t\tlist = list->next;\n+\t\t}\n \t}\n \trevs->commits = newlist;\n }\n@@ -587,10 +623,14 @@\n \t\t\t\trevs->remove_empty_trees = 1;\n \t\t\t\tcontinue;\n \t\t\t}\n-\t\t\tif (!strncmp(arg, \"--no-merges\", 11)) {\n+\t\t\tif (!strcmp(arg, \"--no-merges\")) {\n \t\t\t\trevs->no_merges = 1;\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(arg, \"--boundary\")) {\n+\t\t\t\trevs->boundary = 1;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tif (!strcmp(arg, \"--objects\")) {\n \t\t\t\trevs->tag_objects = 1;\n \t\t\t\trevs->tree_objects = 1;\n@@ -731,13 +771,17 @@\n \tdo {\n \t\tstruct commit *commit = revs->commits->item;\n \n-\t\tif (commit->object.flags & (UNINTERESTING|SHOWN))\n+\t\tif (commit->object.flags & SHOWN)\n+\t\t\tgoto next;\n+\t\tif (!(commit->object.flags & BOUNDARY) &&\n+\t\t (commit->object.flags & UNINTERESTING))\n \t\t\tgoto next;\n \t\tif (revs->min_age != -1 && (commit->date > revs->min_age))\n \t\t\tgoto next;\n \t\tif (revs->max_age != -1 && (commit->date < revs->max_age))\n \t\t\treturn NULL;\n-\t\tif (revs->no_merges && commit->parents && commit->parents->next)\n+\t\tif (revs->no_merges &&\n+\t\t commit->parents && commit->parents->next)\n \t\t\tgoto next;\n \t\tif (revs->prune_fn && revs->dense) {\n \t\t\tif (!(commit->object.flags & TREECHANGE))\n@@ -745,8 +789,12 @@\n \t\t\trewrite_parents(commit);\n \t\t}\n \t\t/* More to go? */\n-\t\tif (revs->max_count)\n-\t\t\tpop_most_recent_commit(&revs->commits, SEEN);\n+\t\tif (revs->max_count) {\n+\t\t\tunsigned flag = SEEN;\n+\t\t\tif (commit->object.flags & BOUNDARY)\n+\t\t\t\tflag |= UNINTERESTING;\n+\t\t\tpop_most_recent_commit(&revs->commits, flag);\n+\t\t}\n \t\tcommit->object.flags |= SHOWN;\n \t\treturn commit;\n next:\ndiff --git a/revision.h b/revision.h\nindex 6c2beca..61e6bc9 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -6,6 +6,7 @@\n #define TREECHANGE\t(1u<<2)\n #define SHOWN\t\t(1u<<3)\n #define TMP_MARK\t(1u<<4) /* for isolated cases; clean after use */\n+#define BOUNDARY\t(1u<<5)\n \n struct rev_info;\n \n@@ -32,7 +33,8 @@\n \t\t\tblob_objects:1,\n \t\t\tedge_hint:1,\n \t\t\tlimited:1,\n-\t\t\tunpacked:1;\n+\t\t\tunpacked:1,\n+\t\t\tboundary:1;\n \n \t/* special limits */\n \tint max_count;\n"},{"id":"18078","messageId":"15693.1143575188@lotus.CS.Berkeley.EDU","threadId":"3740","inReplyTo":"7vu09jks1u.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add ALL_LDFLAGS to the git target.","fromName":"Jason Riedy","fromEmail":"ejr@eecs.berkeley.edu","sentAt":"2006-03-28T19:46:28Z","receivedAt":"2006-03-28T19:46:28Z","isPatch":true,"sender":{"key":"ejr@eecs.berkeley.edu","avatar":"https://gravatar.com/avatar/547fa56f887cab01599edab4e9f813c949c1269e02714f20e0496c56185d9837?d=mp&s=160"},"body":"And Junio C Hamano writes:\n - Hmph. We do fprintf(stderr, \"blah\\r\") to draw them. The\n - standard says that \"standard error stream is not fully\n - buffered\", but I guess it does not necessarily mean it is\n - unbuffered, so we probably need to fflush(3) there. Would\n - something like this help?\n\nI suppose I should have mentioned that I tried flushing \nstderr. Your more comprehensive flushing also does not \nfix it, giving outputs like:\n> Unpacking Total 3333 objects\n> , written 33 (delta 1), reused 0 (delta 0)\n\nThe problem is that stderr from a child is not tied to any \nstream of its parent. Generally, as far as I know, you \ncannot make any assumptions about how pipes from separate \nprocesses are interleaved in the output. Some standard may \nsay something, but I have no idea what or if anyone listens.\nAnd this particular system is a busy SMP node, making the\nproblem worse.\n\nLine-buffered streams like stdout tend to work, but not \nunbuffered streams like stderr. We can't make stderr line-\nbuffered without breaking the status indicator...\n\nIf I add a third fd to all the pipes and dup it to stderr,\nthe tests work. I never read from that fd, so I never get\nthe status output... Progress needs to be part of the \nprotocol so front ends can handle it cleanly rather than \nusing stderr tricks.\n\nSo some possibilities:\n 1) Add the ability to pass options through the whole\n connect system. Then pass -q in the tester.\n 2) Add a specific \"quiet\" command to the protocol for\n just passing -q from git-fetch-pack. Pass -q in the \n tester.\n 3) Add an option to pack-objects that dumps progress\n output to stdout in a special packet format. Then\n update everyone who talks through upload-pack to\n expect another phase of informational messages after\n negotiating object differences and before the pack\n data.\n\nThe first two are cosmetic fixes only, and #2 is a cheap,\nugly, but easy hack.\n\nThis problem is (to me) low priority. It unfortunately \nbreaks a test case on AIX, but I can live with it for now.\nIf others here start to listen to the gospel of git, well,\nI'll need to fix it. (But I once recommended Arch, and\npeople stopped listening after they tried it.)\n\nFolks using moderately-loaded SMPs may experience similar \nproblems. But if they're fetching large packs, the problem\nlikely won't appear at all.\n\nJason\n\nP.S. For the whole finding-a-function-name business, some of \nus are using git on fixed-format Fortran. Every non-comment\nline begins with whitespace... ;) And in free format, many\npeople don't add that first indentation within subroutines.\n"},{"id":"18086","messageId":"slrne2jf9t.s3g.mdw@metalzone.distorted.org.uk","threadId":"3740","inReplyTo":"15693.1143575188@lotus.CS.Berkeley.EDU","subject":"Re: [PATCH] Add ALL_LDFLAGS to the git target.","fromName":"Mark Wooding","fromEmail":"mdw@distorted.org.uk","sentAt":"2006-03-28T22:48:29Z","receivedAt":"2006-03-28T22:48:29Z","isPatch":true,"sender":{"key":"mdw@distorted.org.uk","avatar":null},"body":"Jason Riedy wrote:\n\n> P.S. For the whole finding-a-function-name business, some of \n> us are using git on fixed-format Fortran. Every non-comment\n> line begins with whitespace... ;) And in free format, many\n> people don't add that first indentation within subroutines.\n\nUrgh. So, which regex library do people want to use? ;-) (My vote's\nfor pcre.)\n\n-- [mdw]\n"},{"id":"18087","messageId":"17449.48630.370867.10251@cargo.ozlabs.ibm.com","threadId":"3740","inReplyTo":"7vzmjbj9a1.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk strangeness..","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-03-28T22:51:34Z","receivedAt":"2006-03-28T22:51:34Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Junio C Hamano writes:\n\n> How about this alternative patch, then? It turned out to be\n> quite convoluted as I feared.\n\nThat's brilliant. Thank you! With the patch to gitk below, the\ngraph display on Linus' example looks much saner.\n\nCould you check in your patch to the git.git repository, please?\n\nThanks,\nPaul.\n\ndiff --git a/gitk b/gitk\nindex 03cd475..1989aa5 100755\n--- a/gitk\n+++ b/gitk\n@@ -46,7 +46,7 @@ proc start_rev_list {rlargs} {\n }\n if {[catch {\n \tset commfd [open [concat | git-rev-list --header $order \\\n-\t\t\t --parents $rlargs] r]\n+\t\t\t --parents --boundary $rlargs] r]\n } err]} {\n \tputs stderr \"Error executing git-rev-list: $err\"\n \texit 1\n@@ -114,8 +114,13 @@ proc getcommitlines {commfd} {\n \tset start [expr {$i + 1}]\n \tset j [string first \"\\n\" $cmit]\n \tset ok 0\n+\tset listed 1\n \tif {$j >= 0} {\n \t set ids [string range $cmit 0 [expr {$j - 1}]]\n+\t if {[string range $ids 0 0] == \"-\"} {\n+\t\tset listed 0\n+\t\tset ids [string range $ids 1 end]\n+\t }\n \t set ok 1\n \t foreach id $ids {\n \t\tif {[string length $id] != 40} {\n@@ -133,8 +138,12 @@ proc getcommitlines {commfd} {\n \t exit 1\n \t}\n \tset id [lindex $ids 0]\n-\tset olds [lrange $ids 1 end]\n-\tset commitlisted($id) 1\n+\tif {$listed} {\n+\t set olds [lrange $ids 1 end]\n+\t set commitlisted($id) 1\n+\t} else {\n+\t set olds {}\n+\t}\n \tupdatechildren $id $olds\n \tset commitdata($id) [string range $cmit [expr {$j + 1}] end]\n \tset commitrow($id) $commitidx\n"},{"id":"18089","messageId":"Pine.LNX.4.64.0603281500280.15714@g5.osdl.org","threadId":"3740","inReplyTo":"slrne2jf9t.s3g.mdw@metalzone.distorted.org.uk","subject":"Re: [PATCH] Add ALL_LDFLAGS to the git target.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-28T23:03:05Z","receivedAt":"2006-03-28T23:03:05Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Mar 2006, Mark Wooding wrote:\n\n> Jason Riedy wrote:\n> \n> > P.S. For the whole finding-a-function-name business, some of \n> > us are using git on fixed-format Fortran. Every non-comment\n> > line begins with whitespace... ;) And in free format, many\n> > people don't add that first indentation within subroutines.\n> \n> Urgh. So, which regex library do people want to use? ;-) (My vote's\n> for pcre.)\n\nI'd really just prefer to make the \"-p\" switch configurable, the way it \nwas before. No regexps, just the same rules as for GNU diff, perhaps with \nthe difference being that it would be on by default.\n\nAnother possible approach is to say\n - if the first line of the real diff matches the rules, do NOT add \n another line that matches the rule at the @@-line.\n\nsince the simple @@-line rule really doesn't make sense for any file that \nis \"dense\" (ie where most lines start with non-whitespace).\n\n\t\tLinus\n"},{"id":"18090","messageId":"7vbqvqjgvi.fsf@assigned-by-dhcp.cox.net","threadId":"3740","inReplyTo":"Pine.LNX.4.64.0603281500280.15714@g5.osdl.org","subject":"Re: [PATCH] Add ALL_LDFLAGS to the git target.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-28T23:20:49Z","receivedAt":"2006-03-28T23:20:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 28 Mar 2006, Mark Wooding wrote:\n>\n>> Jason Riedy wrote:\n>> \n>> > P.S. For the whole finding-a-function-name business, some of \n>> > us are using git on fixed-format Fortran. Every non-comment\n>> > line begins with whitespace... ;) And in free format, many\n>> > people don't add that first indentation within subroutines.\n>> \n>> Urgh. So, which regex library do people want to use? ;-) (My vote's\n>> for pcre.)\n>\n> I'd really just prefer to make the \"-p\" switch configurable, the way it \n> was before. No regexps, just the same rules as for GNU diff, perhaps with \n> the difference being that it would be on by default.\n\nStrictly speaking, \"No regexps\" and \"same rules as for GNU diff\"\nare mutually incompatible, since GNU diff -p defaults to\n\"^[[:alpha:]$_]\" but the regexp is configurable.\n\nMy preference is to ignore FORTRAN, keep Mark's current rules,\nperhaps with a way to turn it off if people really find it\nannoying (I do not mind having it always on).\n\n> Another possible approach is to say\n> - if the first line of the real diff matches the rules, do NOT add \n> another line that matches the rule at the @@-line.\n>\n> since the simple @@-line rule really doesn't make sense for any file that \n> is \"dense\" (ie where most lines start with non-whitespace).\n\nI think this is a good rule. If \"the first non-empty line\" may\nbe even better; we do not want to see the name of previous\nfunction for a huke like this:\n\n\t@@ -a,b +c,d @@\n\n int frotz(void)\n {\n ...\n"},{"id":"18091","messageId":"slrne2jh8i.s3g.mdw@metalzone.distorted.org.uk","threadId":"3740","inReplyTo":"Pine.LNX.4.64.0603281500280.15714@g5.osdl.org","subject":"Re: [PATCH] Add ALL_LDFLAGS to the git target.","fromName":"Mark Wooding","fromEmail":"mdw@distorted.org.uk","sentAt":"2006-03-28T23:21:54Z","receivedAt":"2006-03-28T23:21:54Z","isPatch":true,"sender":{"key":"mdw@distorted.org.uk","avatar":null},"body":"Linus Torvalds wrote:\n\n> I'd really just prefer to make the \"-p\" switch configurable, the way\n> it was before. No regexps, just the same rules as for GNU diff,\n\nThe rules for GNU diff aren't actually good enough if you can't\nconfigure them. We used to be able to put runes in GIT_DIFF_OPTS.\n\n> perhaps with the difference being that it would be on by default.\n\nI thought it /was/ on by default:\n\n: static const char *diff_opts = \"-pu\";\n\n(killed in cebff98db).\n\n> Another possible approach is to say\n> - if the first line of the real diff matches the rules, do NOT add \n> another line that matches the rule at the @@-line.\n>\n> since the simple @@-line rule really doesn't make sense for any file that \n> is \"dense\" (ie where most lines start with non-whitespace).\n\nIt's true, and that's an easy fix. But it doesn't do any actual harm.\n\n-- [mdw]\n"},{"id":"18094","messageId":"16397.1143590377@lotus.CS.Berkeley.EDU","threadId":"3740","inReplyTo":"7vbqvqjgvi.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add ALL_LDFLAGS to the git target.","fromName":"Jason Riedy","fromEmail":"ejr@eecs.berkeley.edu","sentAt":"2006-03-28T23:59:37Z","receivedAt":"2006-03-28T23:59:37Z","isPatch":true,"sender":{"key":"ejr@eecs.berkeley.edu","avatar":"https://gravatar.com/avatar/547fa56f887cab01599edab4e9f813c949c1269e02714f20e0496c56185d9837?d=mp&s=160"},"body":"And Junio C Hamano writes:\n - My preference is to ignore FORTRAN, keep Mark's current rules,\n - perhaps with a way to turn it off if people really find it\n - annoying (I do not mind having it always on).\n\nSorry; I had meant my comment as an aside and not a \nrequest. I had never noticed the function definition \nin patches, and now I typically use Emacs's tools.\n\nAnd as of Fortran 90, it's now officially Fortran and\nnot FORTRAN.\n\nJason\n"},{"id":"18095","messageId":"7vmzfai0f7.fsf@assigned-by-dhcp.cox.net","threadId":"3740","inReplyTo":"16397.1143590377@lotus.CS.Berkeley.EDU","subject":"Re: [PATCH] Add ALL_LDFLAGS to the git target.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-29T00:01:32Z","receivedAt":"2006-03-29T00:01:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jason Riedy writes:\n\n> And Junio C Hamano writes:\n> - My preference is to ignore FORTRAN, keep Mark's current rules,\n> - perhaps with a way to turn it off if people really find it\n> - annoying (I do not mind having it always on).\n\nSorry I forgot to add smiley to the above ;-).\n"},{"id":"18097","messageId":"20060329001633.GF27689@pasky.or.cz","threadId":"3740","inReplyTo":"Pine.LNX.4.64.0603281500280.15714@g5.osdl.org","subject":"[PATCH] Support for pickaxe matching regular expressions","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-03-29T00:16:33Z","receivedAt":"2006-03-29T00:16:33Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Mar 29, 2006 at 01:03:05AM CEST, I got a letter\nwhere Linus Torvalds said that...\n> On Tue, 28 Mar 2006, Mark Wooding wrote:\n> > Urgh. So, which regex library do people want to use? ;-) (My vote's\n> > for pcre.)\n> \n> ... No regexps, ...\n\nTo toss a random feature idea around, in the recent days I've found\nmyself thinking about regexp pickaxe several times.\n\nAnd while already tossing stuff, what about a naive proof-of-concept\npatch? A silly example:\n\n\tgit-whatchanged --pickaxe-regex -p -S' +$' | less -p '^[-+ ].* +$'\n\nThen keep hitting 'n'. Good that most of the matches are deletions. :)\n(Or commit messages.)\n\n---\n\ngit-diff-* --pickaxe-regex will change the -S pickaxe to match\nPOSIX extended regular expressions instead of fixed strings.\n\nThe regex.h library is a rather stupid interface and I like pcre too, but\nwith any luck it will be everywhere we will want to run Git on, it being\nPOSIX.2 and all. I'm not sure if we can expect platforms like AIX to\nconform to POSIX.2 or if win32 has regex.h. We might add a flag to\nMakefile if there is a portability trouble potential.\n\nSigned-off-by: Petr Baudis \n---\n\n Documentation/diff-options.txt | 4 ++\n diff.c | 2 +\n diff.h | 1 +\n diffcore-pickaxe.c | 68 ++++++++++++++++++++++++++++++----------\n 4 files changed, 58 insertions(+), 17 deletions(-)\n\ndiff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt\nindex 2a0275e..ec6811c 100644\n--- a/Documentation/diff-options.txt\n+++ b/Documentation/diff-options.txt\n@@ -69,6 +69,10 @@\n \tchangeset, not just the files that contain the change\n \tin .\n \n+--pickaxe-regex::\n+\tMake the not a plain string but an extended POSIX\n+\tregex to match.\n+\n -O::\n \tOutput the patch in the order specified in the\n \t, which has one shell glob pattern per line.\ndiff --git a/diff.c b/diff.c\nindex 8b37477..e006adb 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -883,6 +883,8 @@ int diff_opt_parse(struct diff_options *\n \t\toptions->filter = arg + 14;\n \telse if (!strcmp(arg, \"--pickaxe-all\"))\n \t\toptions->pickaxe_opts = DIFF_PICKAXE_ALL;\n+\telse if (!strcmp(arg, \"--pickaxe-regex\"))\n+\t\toptions->pickaxe_opts = DIFF_PICKAXE_REGEX;\n \telse if (!strncmp(arg, \"-B\", 2)) {\n \t\tif ((options->break_opt =\n \t\t diff_scoreopt_parse(arg)) == -1)\ndiff --git a/diff.h b/diff.h\nindex 8fac465..564c94f 100644\n--- a/diff.h\n+++ b/diff.h\n@@ -112,6 +112,7 @@ #define DIFF_DETECT_RENAME\t1\n #define DIFF_DETECT_COPY\t2\n \n #define DIFF_PICKAXE_ALL\t1\n+#define DIFF_PICKAXE_REGEX\t2\n \n extern void diffcore_std(struct diff_options *);\n \ndiff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c\nindex 50e46ab..d89f314 100644\n--- a/diffcore-pickaxe.c\n+++ b/diffcore-pickaxe.c\n@@ -1,12 +1,15 @@\n /*\n * Copyright (C) 2005 Junio C Hamano\n */\n+#include \n+\n #include \"cache.h\"\n #include \"diff.h\"\n #include \"diffcore.h\"\n \n static unsigned int contains(struct diff_filespec *one,\n-\t\t\t const char *needle, unsigned long len)\n+\t\t\t const char *needle, unsigned long len,\n+\t\t\t regex_t *regexp)\n {\n \tunsigned int cnt;\n \tunsigned long offset, sz;\n@@ -17,15 +20,28 @@ static unsigned int contains(struct diff\n \tsz = one->size;\n \tdata = one->data;\n \tcnt = 0;\n-\n-\t/* Yes, I've heard of strstr(), but the thing is *data may\n-\t * not be NUL terminated. Sue me.\n-\t */\n-\tfor (offset = 0; offset + len <= sz; offset++) {\n-\t\t/* we count non-overlapping occurrences of needle */\n-\t\tif (!memcmp(needle, data + offset, len)) {\n-\t\t\toffset += len - 1;\n+\n+\tif (regexp) {\n+\t\tregmatch_t regmatch;\n+\t\tint flags = 0;\n+\n+\t\twhile (*data && !regexec(regexp, data, 1, ®match, flags)) {\n+\t\t\tflags |= REG_NOTBOL;\n+\t\t\tdata += regmatch.rm_so;\n+\t\t\tif (*data) data++;\n \t\t\tcnt++;\n+\t\t}\n+\n+\t} else { /* Classic exact string match */\n+\t\t/* Yes, I've heard of strstr(), but the thing is *data may\n+\t\t * not be NUL terminated. Sue me.\n+\t\t */\n+\t\tfor (offset = 0; offset + len <= sz; offset++) {\n+\t\t\t/* we count non-overlapping occurrences of needle */\n+\t\t\tif (!memcmp(needle, data + offset, len)) {\n+\t\t\t\toffset += len - 1;\n+\t\t\t\tcnt++;\n+\t\t\t}\n \t\t}\n \t}\n \treturn cnt;\n@@ -36,10 +52,24 @@ void diffcore_pickaxe(const char *needle\n \tstruct diff_queue_struct *q = &diff_queued_diff;\n \tunsigned long len = strlen(needle);\n \tint i, has_changes;\n+\tregex_t regex, *regexp = NULL;\n \tstruct diff_queue_struct outq;\n \toutq.queue = NULL;\n \toutq.nr = outq.alloc = 0;\n \n+\tif (opts & DIFF_PICKAXE_REGEX) {\n+\t\tint err;\n+\t\terr = regcomp(®ex, needle, REG_EXTENDED | REG_NEWLINE);\n+\t\tif (err) {\n+\t\t\t/* The POSIX.2 people are surely sick */\n+\t\t\tchar errbuf[1024];\n+\t\t\tregerror(err, ®ex, errbuf, 1024);\n+\t\t\tregfree(®ex);\n+\t\t\tdie(\"invalid pickaxe regex: %s\", errbuf);\n+\t\t}\n+\t\tregexp = ®ex;\n+\t}\n+\n \tif (opts & DIFF_PICKAXE_ALL) {\n \t\t/* Showing the whole changeset if needle exists */\n \t\tfor (i = has_changes = 0; !has_changes && i < q->nr; i++) {\n@@ -48,16 +78,16 @@ void diffcore_pickaxe(const char *needle\n \t\t\t\tif (!DIFF_FILE_VALID(p->two))\n \t\t\t\t\tcontinue; /* ignore unmerged */\n \t\t\t\t/* created */\n-\t\t\t\tif (contains(p->two, needle, len))\n+\t\t\t\tif (contains(p->two, needle, len, regexp))\n \t\t\t\t\thas_changes++;\n \t\t\t}\n \t\t\telse if (!DIFF_FILE_VALID(p->two)) {\n-\t\t\t\tif (contains(p->one, needle, len))\n+\t\t\t\tif (contains(p->one, needle, len, regexp))\n \t\t\t\t\thas_changes++;\n \t\t\t}\n \t\t\telse if (!diff_unmodified_pair(p) &&\n-\t\t\t\t contains(p->one, needle, len) !=\n-\t\t\t\t contains(p->two, needle, len))\n+\t\t\t\t contains(p->one, needle, len, regexp) !=\n+\t\t\t\t contains(p->two, needle, len, regexp))\n \t\t\t\thas_changes++;\n \t\t}\n \t\tif (has_changes)\n@@ -80,16 +110,16 @@ void diffcore_pickaxe(const char *needle\n \t\t\t\tif (!DIFF_FILE_VALID(p->two))\n \t\t\t\t\t; /* ignore unmerged */\n \t\t\t\t/* created */\n-\t\t\t\telse if (contains(p->two, needle, len))\n+\t\t\t\telse if (contains(p->two, needle, len, regexp))\n \t\t\t\t\thas_changes = 1;\n \t\t\t}\n \t\t\telse if (!DIFF_FILE_VALID(p->two)) {\n-\t\t\t\tif (contains(p->one, needle, len))\n+\t\t\t\tif (contains(p->one, needle, len, regexp))\n \t\t\t\t\thas_changes = 1;\n \t\t\t}\n \t\t\telse if (!diff_unmodified_pair(p) &&\n-\t\t\t\t contains(p->one, needle, len) !=\n-\t\t\t\t contains(p->two, needle, len))\n+\t\t\t\t contains(p->one, needle, len, regexp) !=\n+\t\t\t\t contains(p->two, needle, len, regexp))\n \t\t\t\thas_changes = 1;\n \n \t\t\tif (has_changes)\n@@ -97,6 +127,10 @@ void diffcore_pickaxe(const char *needle\n \t\t\telse\n \t\t\t\tdiff_free_filepair(p);\n \t\t}\n+\n+\tif (opts & DIFF_PICKAXE_REGEX) {\n+\t\tregfree(®ex);\n+\t}\n \n \tfree(q->queue);\n \t*q = outq;\n\n\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nRight now I am having amnesia and deja-vu at the same time. I think\nI have forgotten this before.\n"},{"id":"18102","messageId":"7vacbagjlv.fsf@assigned-by-dhcp.cox.net","threadId":"3740","inReplyTo":"17449.48630.370867.10251@cargo.ozlabs.ibm.com","subject":"Re: Gitk strangeness..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-29T00:50:04Z","receivedAt":"2006-03-29T00:50:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> Junio C Hamano writes:\n>\n>> How about this alternative patch, then? It turned out to be\n>> quite convoluted as I feared.\n>\n> That's brilliant. Thank you! With the patch to gitk below, the\n> graph display on Linus' example looks much saner.\n>\n> Could you check in your patch to the git.git repository, please?\n\nThe patch I sent was a total mess, and the one in \"pu\" right now\nwas somewhat cleaned up but was still far suboptimal. **Blush**\n\nMost notably, the code from yesterday was re-injecting the\nparents of the boundary commits into the list marked as\nUNINTERESTING, which was unnecessary and stupid. This one just\npops boundary commits off the list after consuming it.\n\nHere is a cleaned-up one for eyeballing.\n\nAlthough I am reasonably sure that this does not affect the way\nit works when --boundary is not given, I'd pretty much\nappreciate an independent sanity check on this one. rev-list is\nso fundamental to git.\n\n-- >8 --\ndiff --git a/rev-list.c b/rev-list.c\nindex 441c437..f3a989c 100644\n--- a/rev-list.c\n+++ b/rev-list.c\n@@ -7,9 +7,9 @@ #include \"blob.h\"\n #include \"diff.h\"\n #include \"revision.h\"\n \n-/* bits #0-4 in revision.h */\n+/* bits #0-5 in revision.h */\n \n-#define COUNTED\t\t(1u<<5)\n+#define COUNTED\t\t(1u<<6)\n \n static const char rev_list_usage[] =\n \"git-rev-list [OPTION] ... [ -- paths... ]\\n\"\n@@ -51,6 +51,8 @@ static void show_commit(struct commit *c\n \t\tprintf(\"%lu \", commit->date);\n \tif (commit_prefix[0])\n \t\tfputs(commit_prefix, stdout);\n+\tif (commit->object.flags & BOUNDARY)\n+\t\tputchar('-');\n \tfputs(sha1_to_hex(commit->object.sha1), stdout);\n \tif (show_parents) {\n \t\tstruct commit_list *parents = commit->parents;\ndiff --git a/revision.c b/revision.c\nindex d7678cf..745b0d2 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -419,6 +419,27 @@ static void limit_list(struct rev_info *\n \t\t\tcontinue;\n \t\tp = &commit_list_insert(commit, p)->next;\n \t}\n+\tif (revs->boundary) {\n+\t\tlist = newlist;\n+\t\twhile (list) {\n+\t\t\tstruct commit *commit = list->item;\n+\t\t\tstruct object *obj = &commit->object;\n+\t\t\tstruct commit_list *parent = commit->parents;\n+\t\t\tif (obj->flags & (UNINTERESTING|BOUNDARY)) {\n+\t\t\t\tlist = list->next;\n+\t\t\t\tcontinue;\n+\t\t\t}\n+\t\t\twhile (parent) {\n+\t\t\t\tstruct commit *pcommit = parent->item;\n+\t\t\t\tparent = parent->next;\n+\t\t\t\tif (!(pcommit->object.flags & UNINTERESTING))\n+\t\t\t\t\tcontinue;\n+\t\t\t\tpcommit->object.flags |= BOUNDARY;\n+\t\t\t\tp = &commit_list_insert(pcommit, p)->next;\n+\t\t\t}\n+\t\t\tlist = list->next;\n+\t\t}\n+\t}\n \trevs->commits = newlist;\n }\n \n@@ -591,6 +612,10 @@ int setup_revisions(int argc, const char\n \t\t\t\trevs->no_merges = 1;\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(arg, \"--boundary\")) {\n+\t\t\t\trevs->boundary = 1;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tif (!strcmp(arg, \"--objects\")) {\n \t\t\t\trevs->tag_objects = 1;\n \t\t\t\trevs->tree_objects = 1;\n@@ -731,13 +756,17 @@ struct commit *get_revision(struct rev_i\n \tdo {\n \t\tstruct commit *commit = revs->commits->item;\n \n-\t\tif (commit->object.flags & (UNINTERESTING|SHOWN))\n+\t\tif (commit->object.flags & SHOWN)\n+\t\t\tgoto next;\n+\t\tif (!(commit->object.flags & BOUNDARY) &&\n+\t\t (commit->object.flags & UNINTERESTING))\n \t\t\tgoto next;\n \t\tif (revs->min_age != -1 && (commit->date > revs->min_age))\n \t\t\tgoto next;\n \t\tif (revs->max_age != -1 && (commit->date < revs->max_age))\n \t\t\treturn NULL;\n-\t\tif (revs->no_merges && commit->parents && commit->parents->next)\n+\t\tif (revs->no_merges &&\n+\t\t commit->parents && commit->parents->next)\n \t\t\tgoto next;\n \t\tif (revs->prune_fn && revs->dense) {\n \t\t\tif (!(commit->object.flags & TREECHANGE))\n@@ -745,8 +774,19 @@ struct commit *get_revision(struct rev_i\n \t\t\trewrite_parents(commit);\n \t\t}\n \t\t/* More to go? */\n-\t\tif (revs->max_count)\n-\t\t\tpop_most_recent_commit(&revs->commits, SEEN);\n+\t\tif (revs->max_count) {\n+\t\t\tif (commit->object.flags & BOUNDARY) {\n+\t\t\t\t/* this is already uninteresting,\n+\t\t\t\t * so there is no point popping its\n+\t\t\t\t * parents into the list.\n+\t\t\t\t */\n+\t\t\t\tstruct commit_list *it = revs->commits;\n+\t\t\t\trevs->commits = it->next;\n+\t\t\t\tfree(it);\n+\t\t\t}\n+\t\t\telse\n+\t\t\t\tpop_most_recent_commit(&revs->commits, SEEN);\n+\t\t}\n \t\tcommit->object.flags |= SHOWN;\n \t\treturn commit;\n next:\ndiff --git a/revision.h b/revision.h\nindex 6c2beca..61e6bc9 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -6,6 +6,7 @@ #define UNINTERESTING (1u<<1)\n #define TREECHANGE\t(1u<<2)\n #define SHOWN\t\t(1u<<3)\n #define TMP_MARK\t(1u<<4) /* for isolated cases; clean after use */\n+#define BOUNDARY\t(1u<<5)\n \n struct rev_info;\n \n@@ -32,7 +33,8 @@ struct rev_info {\n \t\t\tblob_objects:1,\n \t\t\tedge_hint:1,\n \t\t\tlimited:1,\n-\t\t\tunpacked:1;\n+\t\t\tunpacked:1,\n+\t\t\tboundary:1;\n \n \t/* special limits */\n \tint max_count;\n"},{"id":"18110","messageId":"7vfyl1bvnn.fsf@assigned-by-dhcp.cox.net","threadId":"3740","inReplyTo":"17449.48630.370867.10251@cargo.ozlabs.ibm.com","subject":"Re: Gitk strangeness..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-29T06:41:00Z","receivedAt":"2006-03-29T06:41:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> That's brilliant. Thank you! With the patch to gitk below, the\n> graph display on Linus' example looks much saner.\n\nIndeed this looks much saner. Thanks.\n"},{"id":"18117","messageId":"Pine.LNX.4.63.0603291340570.1473@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3740","inReplyTo":"slrne2jf9t.s3g.mdw@metalzone.distorted.org.uk","subject":"Re: [PATCH] Add ALL_LDFLAGS to the git target.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-03-29T11:42:00Z","receivedAt":"2006-03-29T11:42:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 28 Mar 2006, Mark Wooding wrote:\n\n> Jason Riedy wrote:\n> \n> > P.S. For the whole finding-a-function-name business, some of \n> > us are using git on fixed-format Fortran. Every non-comment\n> > line begins with whitespace... ;) And in free format, many\n> > people don't add that first indentation within subroutines.\n> \n> Urgh. So, which regex library do people want to use? ;-) (My vote's\n> for pcre.)\n\nMy vote is against adding such a dependency for so little gain. We already \nuse regex.h (probably my fault).\n\nCiao,\nDscho\n"},{"id":"18118","messageId":"20060329130920.GH27689@pasky.or.cz","threadId":"3740","inReplyTo":"Pine.LNX.4.63.0603291340570.1473@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Support for pickaxe matching regular expressions","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-03-29T13:09:20Z","receivedAt":"2006-03-29T13:09:20Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Mar 29, 2006 at 02:16:33AM CEST, I got a letter\nwhere Petr Baudis said that...\n> The regex.h library is a rather stupid interface and I like pcre too, but\n> with any luck it will be everywhere we will want to run Git on, it being\n> POSIX.2 and all. I'm not sure if we can expect platforms like AIX to\n> conform to POSIX.2 or if win32 has regex.h. We might add a flag to\n> Makefile if there is a portability trouble potential.\n\nDear diary, on Wed, Mar 29, 2006 at 01:42:00PM CEST, I got a letter\nwhere Johannes Schindelin said that...\n> We already use regex.h (probably my fault).\n\nIndeed, and since noone complained yet, the portability consideration is\napparently a non-issue.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nRight now I am having amnesia and deja-vu at the same time. I think\nI have forgotten this before.\n"},{"id":"18157","messageId":"20060330205759.GA27131@steel.home","threadId":"3740","inReplyTo":"17449.48630.370867.10251@cargo.ozlabs.ibm.com","subject":"Re: Gitk strangeness..","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-03-30T20:57:59Z","receivedAt":"2006-03-30T20:57:59Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Paul Mackerras, Wed, Mar 29, 2006 00:51:34 +0200:\n> Junio C Hamano writes:\n> \n> > How about this alternative patch, then? It turned out to be\n> > quite convoluted as I feared.\n> \n> That's brilliant. Thank you! With the patch to gitk below, the\n> graph display on Linus' example looks much saner.\n> \n\nWell... Could you take a look at these screenshots, please?\nhttp://home.arcor.de/fork0/bug/gitk1.jpg (this one is BIG, 400k, 2456x949)\nhttp://home.arcor.de/fork0/bug/gitk2.jpg\nhttp://home.arcor.de/fork0/bug/gitk3.jpg\n\nThe compressed repository is being uploaded there:\n\nhttp://home.arcor.de/fork0/bug/ggg.tar.bz2 (~6Mb)\n\nThe old gitk produced a denser graph, which wasn't perfect too, but\nhad a higher count of visible commit titles (and this is two-monitor\nsetup, too).\n"},{"id":"18159","messageId":"17452.23719.400996.78248@cargo.ozlabs.ibm.com","threadId":"3740","inReplyTo":"20060330205759.GA27131@steel.home","subject":"Re: Gitk strangeness..","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-03-30T22:33:11Z","receivedAt":"2006-03-30T22:33:11Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Alex Riesen writes:\n\n> Well... Could you take a look at these screenshots, please?\n> http://home.arcor.de/fork0/bug/gitk1.jpg (this one is BIG, 400k, 2456x949)\n> http://home.arcor.de/fork0/bug/gitk2.jpg\n> http://home.arcor.de/fork0/bug/gitk3.jpg\n\nYes, I was just looking last night at the part of the git.git graph\nthat you have there in gitk1.jpg. That's an artifact of some changes\nI made to make sure there was a vertical line segment just before an\narrow. The reason for doing that is that Tk 8.4 seems to just punt on\ndrawing an arrow on the end of a diagonal line segment. The old gitk\njust removed trailing diagonal segments of the line, but I thought I\ncould do better than that.\n\nI'll try another approach.\n\nPaul.\n"},{"id":"18161","messageId":"17452.28122.129442.49226@cargo.ozlabs.ibm.com","threadId":"3740","inReplyTo":"20060330205759.GA27131@steel.home","subject":"Re: Gitk strangeness..","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-03-30T23:46:34Z","receivedAt":"2006-03-30T23:46:34Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Alex Riesen writes:\n\n> The old gitk produced a denser graph, which wasn't perfect too, but\n> had a higher count of visible commit titles (and this is two-monitor\n> setup, too).\n\nI just pushed a new version which does better on this.\n\nPaul.\n"},{"id":"18166","messageId":"7vek0j1iwu.fsf@assigned-by-dhcp.cox.net","threadId":"3740","inReplyTo":"17452.28122.129442.49226@cargo.ozlabs.ibm.com","subject":"Re: Gitk strangeness..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-31T01:50:57Z","receivedAt":"2006-03-31T01:50:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> Alex Riesen writes:\n>\n>> The old gitk produced a denser graph, which wasn't perfect too, but\n>> had a higher count of visible commit titles (and this is two-monitor\n>> setup, too).\n>\n> I just pushed a new version which does better on this.\n\nThanks. Pulled, merged and pushed out..\n"},{"id":"18169","messageId":"81b0412b0603302227t1580b20awff937ab932ae39bd@mail.gmail.com","threadId":"3740","inReplyTo":"17452.28122.129442.49226@cargo.ozlabs.ibm.com","subject":"Re: Gitk strangeness..","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2006-03-31T06:27:34Z","receivedAt":"2006-03-31T06:27:34Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/31/06, Paul Mackerras wrote:\n>\n> > The old gitk produced a denser graph, which wasn't perfect too, but\n> > had a higher count of visible commit titles (and this is two-monitor\n> > setup, too).\n>\n> I just pushed a new version which does better on this.\n>\n\nThis one looks reallly much better! Thanks!\n"}]}