{"thread":{"id":"3561","subject":"What's in git.git","startedAt":"2006-03-05T04:22:57Z","lastAt":"2006-03-05T20:04:48Z","messageCount":14,"participants":["Junio C Hamano","Linus Torvalds","Martin Langhoff","Alexandre Julliard"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"17163","messageId":"7vacc5jza6.fsf@assigned-by-dhcp.cox.net","threadId":"3561","inReplyTo":null,"subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-05T04:22:57Z","receivedAt":"2006-03-05T04:22:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I've merged up a lot for people to have fun over the weekend\n;-).\n\nThe most notable core-ish change is that rev-list split and new\ngit-log implementation by Linus.  I've been using this myself\nfor a while without problems, but there might still be some\ncorner cases that I (and Linus perhaps) do not exercise where\ngit-log command behaves slightly differently.  rev-list is not\nsupposed to have *any* regression other than removal of\n--merge-order.  Please report regressions.\n\nA new killer application is git-cvsserver.  It now talks pserver\nprotocol for anonymous CVS access.  Helping Martin to audit the\ncode for any issues, security or otherwise, is greatly\nappreciated.\n\nFredrik's git-blame still has -Wdeclaration-after-statement\nissues, but deserves to be beaten harder alongside Ryan's\ngit-annotate for two reasons.  It should be a good example\nprogram to use the new revision traversal infrastructure, and it\nis always good to have competing two implementations ;-).\n\n\n* The 'master' branch has these since the last announcement.\n\n - Cygwin portability for test (Alex Riesen)\n   workaround fat/ntfs deficiencies for t3600-rm.sh (git-rm)\n\n - Emacs interface (Alexandre Julliard)\n   contrib/emacs: Add an Emacs VC backend.\n   git.el: Added customize support for all parameters.\n   git.el: Added support for Signed-off-by.\n   git.el: Automatically update .gitignore status.\n   git.el: Portability fixes for XEmacs and Emacs CVS.\n   git.el: Set default directory before running the status mode setup hooks.\n\n - gitview updates (Aneesh Kumar K.V)\n   gitview: Use horizontal scroll bar in the tree view\n   gitview: pass the missing argument _show_clicked_cb.\n\n - git-svn updates (Eric Wong)\n   contrib/git-svn: add --id/-i=$GIT_SVN_ID command-line switch\n   contrib/git-svn: add -b/--branch switch for branch detection\n   contrib/git-svn: allow --authors-file to be specified\n   contrib/git-svn: avoid re-reading the repository uuid, it never changes\n   contrib/git-svn: better documenting of CLI switches\n   contrib/git-svn: cleanup option parsing\n   contrib/git-svn: create a more recent master if one does not exist\n   contrib/git-svn: fix a copied-tree bug in an overzealous assertion\n   contrib/git-svn: several small bug fixes and changes\n   contrib/git-svn: strip 'git-svn-id:' when commiting to SVN\n   contrib/git-svn: use refs/remotes/git-svn instead of git-svn-HEAD\n   git-branch: add -r switch to list refs/remotes/*\n\n - send-email fix (Eric Wong)\n   send-email: accept --no-signed-off-by-cc as the documentation states\n\n - checkout-index --stdin (Shawn Pearce)\n   Teach git-checkout-index to read filenames from stdin.\n\n - git-blame (Fredrik Kuivinen)\n   Add git-blame, a tool for assigning blame.\n   git-blame, take 2\n\n - git-mv updates (Josef Weidendorfer)\n   git-mv: Allow -h without repo & fix error message\n   git-mv: fixes for path handling\n   git-mv: fix moves into a subdir from outside\n\n - split rev-list implementation and git-log (Linus and me)\n   First cut at libifying revlist generation\n   Splitting rev-list into revisions lib, end of beginning.\n   git-rev-list libification: rev-list walking\n   Introduce trivial new pager.c helper infrastructure\n   Tie it all together: \"git log\"\n   Rip out merge-order and make \"git log <paths>...\" work again.\n   rev-list split: minimum fixup.\n   git-log (internal): add approxidate.\n   git-log (internal): more options.\n   setup_revisions(): handle -n<n> and -<n> internally.\n\n - git-verify-tag update (me)\n   Pretty-print tagger dates.\n\n - git-commit --amend (me) \n\n - show-branch --topics (me)\n\n - git-svnimport update (Karl  Hasselström)\n   Save username -> Full Name <email@addr.es> map file\n\n - git tool survey documentation (Marco Costalba)\n   Add a Documentation/git-tools.txt\n\n - git-cvsserver updates (Martin Langhoff)\n   cvsserver: Checkout correctly on Eclipse\n   annotate: fix -S parameter to take a string\n   cvsserver: Eclipse compat -- now \"compare with latest from HEAD\" works\n   cvsserver: checkout faster by sending files in a sensible order\n   cvsserver: fix checkouts with -d <somedir>\n   cvsserver: nested directory creation fixups for Eclipse clients\n   cvsserver: better error messages\n   cvsserver: anonymous cvs via pserver support\n\n - delta cleanup (Nicolas Pitre)\n   relax delta selection filtering in pack-objects\n   diff-delta: fold two special tests into one plus cleanups\n   diff-delta: big code simplification\n\n - git-annotate updates (Ryan Anderson)\n   annotate: handle \\No newline at end of file.\n   annotate: Add a basic set of test cases.\n\n - misc fixes and docs (Francis Daly, Johannes Schindelin, Jonas Fonseca,\n   Mark Wooding, Shawn Pearce, Tony Luck, Martin Langhoff, me)\n   AsciiDoc fix for tutorial\n   Documentation: read-tree --aggressive\n   Documentation: rev-list --objects-edge\n   Fix test case for some sed\n   GIT-VERSION-GEN: squelch unneeded error from \"cat version\"\n   Prevent --index-info from ignoring -z.\n   Pull GIT 1.2.4 fixes from master\n   Re-fix compilation warnings.\n   Warn about invalid refs\n   annotate should number lines starting with 1\n   annotate: fix -S parameter to take a string\n   annotate: resurrect raw timestamps.\n   combine-diff: Honour --full-index.\n   combine-diff: Honour -z option correctly.\n   git-commit: make sure we protect against races.\n   manpages: insert two missing [verse] markers for multi-line SYNOPSIS\n   read-tree --aggressive: remove deleted entry from the working tree.\n   tar-tree: file/dirmode fix.\n   war on whitespaces: documentation.\n\n* The 'next' branch, in addition, has these.\n\n - diffcore-rename/break and similarity estimator tweaks (me)\n   count-delta: no need for this anymore.\n   diffcore-break: similarity estimator fix.\n   diffcore-delta: make change counter to byte oriented again.\n   diffcore-rename: similarity estimator fix.\n\n* The 'pu' branch, in addition, has these.\n\n - checkout-index --temp --stage=all (Shawn Pearce)\n"},{"id":"17164","messageId":"7v4q2djxy9.fsf@assigned-by-dhcp.cox.net","threadId":"3561","inReplyTo":"7vacc5jza6.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-05T04:51:42Z","receivedAt":"2006-03-05T04:51:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Fredrik's git-blame still has -Wdeclaration-after-statement\n> issues,...\n\nQuick correction before anybody says anything.\n\nSorry Fredrik, there is none anymore --- you have already done\nclean-up and I merged it.  Just \"print_map defined but not used\".\n"},{"id":"17165","messageId":"Pine.LNX.4.64.0603042058250.13139@g5.osdl.org","threadId":"3561","inReplyTo":"7vacc5jza6.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-05T04:58:41Z","receivedAt":"2006-03-05T04:58:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOn Sat, 4 Mar 2006, Junio C Hamano wrote:\n> \n> The most notable core-ish change is that rev-list split and new\n> git-log implementation by Linus.  I've been using this myself\n> for a while without problems, but there might still be some\n> corner cases that I (and Linus perhaps) do not exercise where\n> git-log command behaves slightly differently.  rev-list is not\n> supposed to have *any* regression other than removal of\n> --merge-order.  Please report regressions.\n\nHere's a potential fix for a special case that we used to have to make\n\n\tgit-rev-list --max-count=1\n\nbe faster and not unnecessarily parse any parent objects.\n\nNow, we had that special case because gitweb was apparently doing a lot of \nit, and quite frankly, I don't know if it still does. But basically it \navoids doing the \"pop_most_recent_commit()\" which will look up and parse \nthe parents, if it is obvious that it can.\n\nI'm not sure this is worth it, but it looks obvious enough. Somebody with \ngitweb somewhere should probably check if it still even wants this.\n\n\t\tLinus\n\n----\ndiff --git a/revision.c b/revision.c\nindex a3df810..33a5f20 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -696,6 +696,18 @@ struct commit *get_revision(struct rev_i\n \t\tbreak;\n \tcase 0:\n \t\treturn NULL;\n+\n+\t/* Special case to avoid unnecessary parent checking */\n+\tcase 1:\n+\t\tif (!revs->limited &&\n+\t\t    !revs->no_merges &&\n+\t\t    !revs->paths &&\n+\t\t    revs->min_age == -1 &&\n+\t\t    revs->max_age == -1) {\n+\t\t    \trevs->max_count = 0;\n+\t\t\tcommit->object.flags |= SHOWN;\n+\t\t\treturn commit;\n+\t\t}\n \tdefault:\n \t\trevs->max_count--;\n \t}\n"},{"id":"17167","messageId":"7vfylxigxc.fsf@assigned-by-dhcp.cox.net","threadId":"3561","inReplyTo":"Pine.LNX.4.64.0603042058250.13139@g5.osdl.org","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-05T05:44:47Z","receivedAt":"2006-03-05T05:44:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> I'm not sure this is worth it, but it looks obvious enough. Somebody with \n> gitweb somewhere should probably check if it still even wants this.\n\nI just pulled and it's still v264 (Jan 17 2006).  It does it in\none sub (git_read_commit) to read a single commit and the sub is\ncalled from almost everywhere, so it would help.\n\nHaving said that...\n\n> diff --git a/revision.c b/revision.c\n> index a3df810..33a5f20 100644\n> --- a/revision.c\n> +++ b/revision.c\n> @@ -696,6 +696,18 @@ struct commit *get_revision(struct rev_i\n>  \t\tbreak;\n>  \tcase 0:\n>  \t\treturn NULL;\n> +\n> +\t/* Special case to avoid unnecessary parent checking */\n> +\tcase 1:\n> +\t\tif (!revs->limited &&\n> +\t\t    !revs->no_merges &&\n> +\t\t    !revs->paths &&\n> +\t\t    revs->min_age == -1 &&\n> +\t\t    revs->max_age == -1) {\n> +\t\t    \trevs->max_count = 0;\n> +\t\t\tcommit->object.flags |= SHOWN;\n> +\t\t\treturn commit;\n> +\t\t}\n\nAt this point commit is revs->commits->item.  It cannot be\nUNINTERESTING because you make it sure with !revs->limited and\nfriends, but I wonder if it can be SHOWN already for some\nreason, in which case returning it is wrong.\n\nUnlike the earlier special case in rev-list, this special case\nkicks in for the last iteration of repeated calls to\nget_revision() (e.g. third iteration of \"rev-list -3\")...\n"},{"id":"17171","messageId":"46a038f90603050121u6bccbb71ve78de69ae45b96ad@mail.gmail.com","threadId":"3561","inReplyTo":"7vacc5jza6.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-03-05T09:21:46Z","receivedAt":"2006-03-05T09:21:46Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 3/5/06, Junio C Hamano <junkio@cox.net> wrote:\n>  - Emacs interface (Alexandre Julliard)\n>    contrib/emacs: Add an Emacs VC backend.\n>    git.el: Added customize support for all parameters.\n>    git.el: Added support for Signed-off-by.\n>    git.el: Automatically update .gitignore status.\n>    git.el: Portability fixes for XEmacs and Emacs CVS.\n>    git.el: Set default directory before running the status mode setup hooks.\n\nI'm somewhat confused by the fact that there are two emacs modes, both\nby Alexandre. Which one should I use? Also -- the killer app for\nemacs+git would be to leverage the great patch-editing mode in emacs.\n\nCan we get a new merge conflict mode that generates .rej files? Emacs\nis superb at dealing with conflicts formatted that way. OTOH, it may\nbe able to deal smartly with diff3-style conflicts if it knows how to\ntalk with the VC backend -- I think the cvs mode can do that.\n\nLinus has mentioned several times that it is more important to have\nwell oiled tools to deal with conflicts when they happen -- easy\nvisualization of what the different versions were, commit msgs,\nhighlight characters that don't match in a line that looks the same at\nfirst glance, etc -- than to try and magically resolve conflicts. I'm\nin violent agreement, and keen on seeing the emacs vc stuff fill that\ngap.\n\n(of course, if xxdiff and others can help, that'd be cool too, but\ncurrently they seem strangely unable to deal with files with diff3\nconflict markers.)\n\n>  - git-cvsserver updates (Martin Langhoff)\n\nWohoo! This needs testers -- give it a whirl, please! BTW, the\nworkarounds for Eclipse mentioned in the doco are no longer needed.\nStill, you do want to give Documentation/git-cvsserver.txt a quick\nread.\n\ncheers,\n\n\nmartin\n"},{"id":"17177","messageId":"87irqtjjr1.fsf@wine.dyndns.org","threadId":"3561","inReplyTo":"46a038f90603050121u6bccbb71ve78de69ae45b96ad@mail.gmail.com","subject":"Re: What's in git.git","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2006-03-05T09:58:26Z","receivedAt":"2006-03-05T09:58:26Z","isPatch":false,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"\"Martin Langhoff\" <martin.langhoff@gmail.com> writes:\n\n> I'm somewhat confused by the fact that there are two emacs modes, both\n> by Alexandre. Which one should I use? Also -- the killer app for\n> emacs+git would be to leverage the great patch-editing mode in emacs.\n\nYou can use both. The VC backend is a per-file mode, that's handy when\nyou are editing a file and want a quick diff/revert/commit of just\nthat file; the commands are executed directly from the buffer\ncontaining the file. When making bigger changes, you should use the\ngit-status mode (the one in git.el), which is a tree browser that\ngives you a view of the whole project.\n\n> Can we get a new merge conflict mode that generates .rej files? Emacs\n> is superb at dealing with conflicts formatted that way. OTOH, it may\n> be able to deal smartly with diff3-style conflicts if it knows how to\n> talk with the VC backend -- I think the cvs mode can do that.\n\nWhat emacs mode do you use to resolve conflicts?  From the git-status\nbuffer, if you edit a file with 'f' it will automatically turn on\nsmerge mode if there are conflicts, or you can edit it in ediff merge\nmode with 'd E' like under pcl-cvs. Is that what you mean?\n\n-- \nAlexandre Julliard\njulliard@winehq.org\n"},{"id":"17178","messageId":"7vy7zpgq1i.fsf@assigned-by-dhcp.cox.net","threadId":"3561","inReplyTo":"46a038f90603050121u6bccbb71ve78de69ae45b96ad@mail.gmail.com","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-05T10:10:49Z","receivedAt":"2006-03-05T10:10:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" <martin.langhoff@gmail.com> writes:\n\n> I'm somewhat confused by the fact that there are two emacs modes, both\n> by Alexandre. Which one should I use? Also -- the killer app for\n> emacs+git would be to leverage the great patch-editing mode in emacs.\n\nThey are different styles.  I've been in VC camp but my\nunderstanding is pcl-cvs style integration is closer to\nwhole-tree than VC which is more per-file.  I still haven't\nadjusted to pcl-cvs style yet..\n\n> (of course, if xxdiff and others can help, that'd be cool too, but\n> currently they seem strangely unable to deal with files with diff3\n> conflict markers.)\n\nI had pleasant experiences with \"xxdiff -U\".\n"},{"id":"17181","messageId":"46a038f90603050215v7afcbd4crc145e85a4da416a7@mail.gmail.com","threadId":"3561","inReplyTo":"87irqtjjr1.fsf@wine.dyndns.org","subject":"Re: What's in git.git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-03-05T10:15:31Z","receivedAt":"2006-03-05T10:15:31Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 3/5/06, Alexandre Julliard <julliard@winehq.org> wrote:\n> You can use both. The VC backend is a per-file mode, that's handy when\n> you are editing a file and want a quick diff/revert/commit of just\n> that file; the commands are executed directly from the buffer\n> containing the file. When making bigger changes, you should use the\n> git-status mode (the one in git.el), which is a tree browser that\n> gives you a view of the whole project.\n\nSo I should use a combination of both? Hmmm. Worth exploring, can you\ngive us a quick guide on getting started with it? (Or where should I\nread? I'm not that good with emacs)...\n\n> > Can we get a new merge conflict mode that generates .rej files? Emacs\n> > is superb at dealing with conflicts formatted that way. OTOH, it may\n> > be able to deal smartly with diff3-style conflicts if it knows how to\n> > talk with the VC backend -- I think the cvs mode can do that.\n>\n> What emacs mode do you use to resolve conflicts?  From the git-status\n> buffer, if you edit a file with 'f' it will automatically turn on\n> smerge mode if there are conflicts, or you can edit it in ediff merge\n> mode with 'd E' like under pcl-cvs. Is that what you mean?\n\nOh. Ah. Ok! I'll have to try this! So far, I've had good luck\nfollowing this guide:\n\n    http://wiki.gnuarch.org/Process_20_2a_2erej_20files\n\nwhich is targetted pretty much at dumb emacs users. Like me ;-)\n\n\nmartin\n"},{"id":"17184","messageId":"87bqwljhgn.fsf@wine.dyndns.org","threadId":"3561","inReplyTo":"46a038f90603050215v7afcbd4crc145e85a4da416a7@mail.gmail.com","subject":"Re: What's in git.git","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2006-03-05T10:47:52Z","receivedAt":"2006-03-05T10:47:52Z","isPatch":false,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"\"Martin Langhoff\" <martin.langhoff@gmail.com> writes:\n\n> So I should use a combination of both? Hmmm. Worth exploring, can you\n> give us a quick guide on getting started with it? (Or where should I\n> read? I'm not that good with emacs)...\n\nTo get started with the VC backend, make sure vc-git.el is somewhere\non your emacs load-path, and add GIT to the vc-handled-backends\nvariable; the easiest is with customize, something like\n`M-x customize-variable [RET] vc-handled-backends'.\n\nOnce you have done that, when you open a file that's under git\ncontrol, the vc-git mode should automatically be turned on, and you\nshould see a \"GIT\" indicator in the modeline. Then you can use the\nstandard VC backend commands (the ones that start with the C-x v\nprefix). The Emacs VC mode is documented at:\n\n  http://www.gnu.org/software/emacs/manual/html_node/Version-Control.html\n\nFor the git-status mode, simply do a `M-x load-file [RET] git.el', and\nthen `M-x git-status'. This will prompt you for the directory to view,\nand display a list of modified files. From there you can mark files\nand perform actions on group of files, like diff, commit, revert, etc.\nThere isn't a lot of documentation at this point, but a `C-h m' will\nshow you the list of key bindings, so you can try them all and see\nwhat happens ;-)\n\n> Oh. Ah. Ok! I'll have to try this! So far, I've had good luck\n> following this guide:\n>\n>     http://wiki.gnuarch.org/Process_20_2a_2erej_20files\n>\n> which is targetted pretty much at dumb emacs users. Like me ;-)\n\nsmerge mode is a very simple mode to edit files that contain conflict\nmarkers, in my experience it works pretty well. The nice thing is that\nit works directly from the file buffer, so you don't need to jump back\nand forth between file and diff.\n\n-- \nAlexandre Julliard\njulliard@winehq.org\n"},{"id":"17195","messageId":"Pine.LNX.4.64.0603050946280.13139@g5.osdl.org","threadId":"3561","inReplyTo":"7vfylxigxc.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-05T17:53:52Z","receivedAt":"2006-03-05T17:53:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 4 Mar 2006, Junio C Hamano wrote:\n> \n> At this point commit is revs->commits->item.  It cannot be\n> UNINTERESTING because you make it sure with !revs->limited and\n> friends, but I wonder if it can be SHOWN already for some\n> reason, in which case returning it is wrong.\n> \n> Unlike the earlier special case in rev-list, this special case\n> kicks in for the last iteration of repeated calls to\n> get_revision() (e.g. third iteration of \"rev-list -3\")...\n\nGood point. Yes, it needs to check that it's not SHOWN. Might as well \ncheck against interesting too. Maybe something like this instead?\n\n\t\tLinus\n\n---\ndiff --git a/revision.c b/revision.c\nindex a3df810..2a33637 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -684,13 +684,11 @@ static void rewrite_parents(struct commi\n struct commit *get_revision(struct rev_info *revs)\n {\n \tstruct commit_list *list = revs->commits;\n-\tstruct commit *commit;\n \n \tif (!list)\n \t\treturn NULL;\n \n \t/* Check the max_count ... */\n-\tcommit = list->item;\n \tswitch (revs->max_count) {\n \tcase -1:\n \t\tbreak;\n@@ -701,22 +699,28 @@ struct commit *get_revision(struct rev_i\n \t}\n \n \tdo {\n-\t\tcommit = pop_most_recent_commit(&revs->commits, SEEN);\n+\t\tstruct commit *commit = revs->commits->item;\n+\n \t\tif (commit->object.flags & (UNINTERESTING|SHOWN))\n-\t\t\tcontinue;\n+\t\t\tgoto next;\n \t\tif (revs->min_age != -1 && (commit->date > revs->min_age))\n-\t\t\tcontinue;\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\t\tcontinue;\n+\t\t\tgoto next;\n \t\tif (revs->paths && revs->dense) {\n \t\t\tif (!(commit->object.flags & TREECHANGE))\n-\t\t\t\tcontinue;\n+\t\t\t\tgoto next;\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\tcommit->object.flags |= SHOWN;\n \t\treturn commit;\n+next:\n+\t\tpop_most_recent_commit(&revs->commits, SEEN);\n \t} while (revs->commits);\n \treturn NULL;\n }\n"},{"id":"17196","messageId":"Pine.LNX.4.64.0603051027400.13139@g5.osdl.org","threadId":"3561","inReplyTo":"Pine.LNX.4.64.0603050946280.13139@g5.osdl.org","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-05T18:29:31Z","receivedAt":"2006-03-05T18:29:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 5 Mar 2006, Linus Torvalds wrote:\n> \n> Good point. Yes, it needs to check that it's not SHOWN. Might as well \n> check against interesting too. Maybe something like this instead?\n\nActually, thinking more about it, I think we could get rid of SHOWN.\n\nWe only ever insert a commit _once_ onto the list, using the SEEN logic, \nso we can never pull the same commit off the list more than once. I think \nSHOWN was for merge-order.\n\nBut I might be wrong. I was thinking about SHOWN a bit when I did the \nre-organization, but didn't dare to actually touch it, so I left it alone.\n\n\t\tLinus\n"},{"id":"17200","messageId":"7vwtf8fzvb.fsf@assigned-by-dhcp.cox.net","threadId":"3561","inReplyTo":"Pine.LNX.4.64.0603051027400.13139@g5.osdl.org","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-05T19:36:08Z","receivedAt":"2006-03-05T19:36:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> Actually, thinking more about it, I think we could get rid of SHOWN.\n>\n> We only ever insert a commit _once_ onto the list, using the SEEN logic, \n> so we can never pull the same commit off the list more than once. I think \n> SHOWN was for merge-order.\n>\n> But I might be wrong. I was thinking about SHOWN a bit when I did the \n> re-organization, but didn't dare to actually touch it, so I left it alone.\n\nI abused SHOWN when I did --objects-edge with\nmark_edge_parents_uninteresting modification in\neb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4, but probably it can be\nmodified to use SEEN.\n"},{"id":"17201","messageId":"7vk6b8fz1x.fsf@assigned-by-dhcp.cox.net","threadId":"3561","inReplyTo":"Pine.LNX.4.64.0603051027400.13139@g5.osdl.org","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-05T19:53:46Z","receivedAt":"2006-03-05T19:53:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I was going through 'whatchanged rev-list.c' but was half-way\nwhen I sent the previous message.  -S'UNINTERESTING|SHOWN' found\nthis one.\n\n51b1e1713b1ed8e962e994cd0850ea439ad8c3de\nAuthor: Jon Seymour <jon.seymour@gmail.com>\nDate:   Mon Jun 20 12:29:38 2005 +1000\n\n    [PATCH] Prevent git-rev-list without --merge-order producing\n    dupicates in output\n\n    If b is reachable from a, then:\n\n         git-rev-list a b\n\n    argument would print one of the commits twice.\n\n    This patch fixes that problem. A previous problem fixed it\n    for the --merge-order switch.\n\n    Signed-off-by: Jon Seymour <jon.seymour@gmail.com>\n    Signed-off-by: Linus Torvalds <torvalds@osdl.org>\n"},{"id":"17202","messageId":"Pine.LNX.4.64.0603051203060.13139@g5.osdl.org","threadId":"3561","inReplyTo":"7vwtf8fzvb.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-05T20:04:48Z","receivedAt":"2006-03-05T20:04:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 5 Mar 2006, Junio C Hamano wrote:\n> \n> I abused SHOWN when I did --objects-edge with\n> mark_edge_parents_uninteresting modification in\n> eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4, but probably it can be\n> modified to use SEEN.\n\nAhh, no. SEEN is different from SHOWN. SHOWN means that we've actually \nshown that commit, while SEEN just means that we've added it to the list \n(but it might be uninteresting, for example). I think you did exactly the \nright thing wrt SHOWN.\n\nThat said, the revision list walker should never see a SHOWN commit on the \nlist, because it is the thing that sets SHOWN as it removes the entry from \nthe list (and it should never get re-added, due to SEEN).\n\n\t\tLinus\n"}]}