{"thread":{"id":"4835","subject":"git-log to go forward instead of reverse?","startedAt":"2006-07-10T18:42:30Z","lastAt":"2006-07-10T21:45:11Z","messageCount":11,"participants":["Randal L. Schwartz","Linus Torvalds","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"23563","messageId":"86bqrxpai1.fsf@blue.stonehenge.com","threadId":"4835","inReplyTo":null,"subject":"git-log to go forward instead of reverse?","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-07-10T18:42:30Z","receivedAt":"2006-07-10T18:42:30Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":"\nAm I missing an option to have git-log go forward in time rather than\nbackward? I'd really like \"git-log --pretty=short ORIG_HEAD..HEAD\" to show me\na story I can read. :)\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"23566","messageId":"Pine.LNX.4.64.0607101151470.5623@g5.osdl.org","threadId":"4835","inReplyTo":"86bqrxpai1.fsf@blue.stonehenge.com","subject":"Re: git-log to go forward instead of reverse?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-10T19:01:54Z","receivedAt":"2006-07-10T19:01:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 10 Jul 2006, Randal L. Schwartz wrote:\n> \n> Am I missing an option to have git-log go forward in time rather than\n> backward? I'd really like \"git-log --pretty=short ORIG_HEAD..HEAD\" to show me\n> a story I can read. :)\n\nWell, as long as you realize that that automatically means that you have \nto walk the whole commit list, and you won't be able to get the \nincremental output that git-log and friends normally are able to give?\n\nBut this patch should do it. With it,\n\n\tgit log --reverse --pretty=short ORIG_HEAD..\n\nshould do what you want.\n\nIt is _not_ possible to reverse the \"gitk\" view with this patch, though, \nas this does _not_ reverse parenthood information.\n\nThe \"--reverse\" flag could possibly be renamed. \n\n\t\tLinus\n\n---\ndiff --git a/revision.c b/revision.c\nindex 7df9089..13a3e40 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -698,6 +698,10 @@ int setup_revisions(int argc, const char\n \t\t\t\trevs->topo_order = 1;\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(arg, \"--reverse\")) {\n+\t\t\t\trevs->reverse ^= 1;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tif (!strcmp(arg, \"--parents\")) {\n \t\t\t\trevs->parents = 1;\n \t\t\t\tcontinue;\n@@ -921,7 +925,7 @@ int setup_revisions(int argc, const char\n \t\tadd_pending_object(revs, object, def);\n \t}\n \n-\tif (revs->topo_order || revs->unpacked)\n+\tif (revs->topo_order || revs->unpacked || revs->reverse)\n \t\trevs->limited = 1;\n \n \tif (revs->prune_data) {\n@@ -941,6 +945,19 @@ int setup_revisions(int argc, const char\n \treturn left;\n }\n \n+static struct commit_list *reverse_commit_list(struct commit_list *p)\n+{\n+\tstruct commit_list *result = NULL;\n+\n+\twhile (p) {\n+\t\tstruct commit_list *next = p->next;\n+\t\tp->next = result;\n+\t\tresult = p;\n+\t\tp = next;\n+\t}\n+\treturn result;\n+}\n+\n void prepare_revision_walk(struct rev_info *revs)\n {\n \tint nr = revs->pending.nr;\n@@ -968,6 +985,8 @@ void prepare_revision_walk(struct rev_in\n \t\tsort_in_topological_order_fn(&revs->commits, revs->lifo,\n \t\t\t\t\t revs->topo_setter,\n \t\t\t\t\t revs->topo_getter);\n+\tif (revs->reverse)\n+\t\trevs->commits = reverse_commit_list(revs->commits);\n }\n \n static int rewrite_one(struct rev_info *revs, struct commit **pp)\ndiff --git a/revision.h b/revision.h\nindex c010a08..ff6ce44 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -32,6 +32,7 @@ struct rev_info {\n \t\t\tremove_empty_trees:1,\n \t\t\tsimplify_history:1,\n \t\t\tlifo:1,\n+\t\t\treverse:1,\n \t\t\ttopo_order:1,\n \t\t\ttag_objects:1,\n \t\t\ttree_objects:1,\n"},{"id":"23567","messageId":"863bd9p9en.fsf@blue.stonehenge.com","threadId":"4835","inReplyTo":"Pine.LNX.4.64.0607101151470.5623@g5.osdl.org","subject":"Re: git-log to go forward instead of reverse?","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-07-10T19:06:08Z","receivedAt":"2006-07-10T19:06:08Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Linus\" == Linus Torvalds writes:\n\nLinus> Well, as long as you realize that that automatically means that you\nLinus> have to walk the whole commit list, and you won't be able to get the\nLinus> incremental output that git-log and friends normally are able to give?\n\nWow. Yes, I think I can live with that for the application.\n\nLinus> But this patch should do it.\n\nThanks!\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"23569","messageId":"Pine.LNX.4.64.0607101212410.5623@g5.osdl.org","threadId":"4835","inReplyTo":"863bd9p9en.fsf@blue.stonehenge.com","subject":"Re: git-log to go forward instead of reverse?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-10T19:20:45Z","receivedAt":"2006-07-10T19:20:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 10 Jul 2006, Randal L. Schwartz wrote:\n> \n> Linus> Well, as long as you realize that that automatically means that you\n> Linus> have to walk the whole commit list, and you won't be able to get the\n> Linus> incremental output that git-log and friends normally are able to give?\n> \n> Wow. Yes, I think I can live with that for the application.\n\nIt's a big deal for me, I often end up doing things like\n\n\tgit log -p some-random-file\n\nto see what has happened, and getting the most recent changes basically \ninstantaneously (rather than waiting for the thing to traverse all of the \nhistory) is a big deal.\n\nIf you have a fairly small archive, or you don't use pathname limiting, \nthe history generation is so fast that you'll never even notice. But with \nthe kernel, doing something like\n\n\tgit log drivers/serial\n\ntakes just over two seconds for me, and if I had to wait for two seconds \nbefore the first data starts arriving, I'd go nuts.\n\nTo see this in cold hard numbers:\n\n\t// Full log\n\t[torvalds@g5 linux]$ time git log drivers/serial > /dev/null \n\n\treal 0m2.267s\n\tuser 0m2.204s\n\tsys 0m0.020s\n\n\t// Simulate \"get the first screenful\"\n\t[torvalds@g5 linux]$ time git log drivers/serial | head -25 > /dev/null \n\n\treal 0m0.054s\n\tuser 0m0.048s\n\tsys 0m0.008s\n\n\t// Simulate \"get the first screenful of reverse output\"\n\t[torvalds@g5 linux]$ time git log --reverse drivers/serial | head > /dev/null \n\n\treal 0m2.218s\n\tuser 0m2.176s\n\tsys 0m0.044s\n\nand it's the difference between the second and the third case I wanted to \npoint out.\n\nThe difference between getting the first screenful in 0.054 seconds versus \nit taking 2.218 seconds is quite noticeable, and one of the things I've \nactually spent a fair amount of time on is to make sure that the \nincremental output case is the _common_ one for all the normal operations \nlike \"git log -p\".\n\n\t\t\tLinus\n"},{"id":"23570","messageId":"86mzbhntxu.fsf@blue.stonehenge.com","threadId":"4835","inReplyTo":"Pine.LNX.4.64.0607101212410.5623@g5.osdl.org","subject":"Re: git-log to go forward instead of reverse?","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-07-10T19:25:33Z","receivedAt":"2006-07-10T19:25:33Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Linus\" == Linus Torvalds writes:\n\n>> Wow. Yes, I think I can live with that for the application.\n\nLinus> It's a big deal for me, I often end up doing things like\n\nLinus> \tgit log -p some-random-file\n\nLinus> to see what has happened, and getting the most recent changes basically \nLinus> instantaneously (rather than waiting for the thing to traverse all of the \nLinus> history) is a big deal.\n\nWell, this is for a \"I'm connected to the net right now: please\nrefresh all of my git mirrors\" script:\n\n ## (code here to cd to the right dir omitted)\n git-fetch\n if git-status | grep -v 'nothing to commit'\n then echo UPDATE SKIPPED\n else\n if git-pull . origin | egrep -v 'up-to-date'\n then git-log --pretty=short ORIG_HEAD..HEAD | cat\n fi\n fi\n\nThe log is just so I can quickly eyeball the interesting changes. The \"cat\"\nis to keep git-log from starting a pager. (If there's a switch that does\n*that* that I've overlooked, that'd be good too.)\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"23571","messageId":"Pine.LNX.4.64.0607101221170.5623@g5.osdl.org","threadId":"4835","inReplyTo":"Pine.LNX.4.64.0607101212410.5623@g5.osdl.org","subject":"Re: git-log to go forward instead of reverse?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-10T19:26:23Z","receivedAt":"2006-07-10T19:26:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 10 Jul 2006, Linus Torvalds wrote:\n> \n> The difference between getting the first screenful in 0.054 seconds versus \n> it taking 2.218 seconds is quite noticeable, and one of the things I've \n> actually spent a fair amount of time on is to make sure that the \n> incremental output case is the _common_ one for all the normal operations \n> like \"git log -p\".\n\nSide note: the good news is that even with the reverse generation, if you \nalso generate _diffs_, the diffs will be generated incrementally, so:\n\n\t// Full \"git log\" with diffs\n\t[torvalds@g5 linux]$ time git log -p drivers/serial > /dev/null \n\n\treal 0m3.409s\n\tuser 0m3.360s\n\tsys 0m0.052s\n\n\t// First screenful of reverse git log with diffs\n\t[torvalds@g5 linux]$ time git log -p --reverse drivers/serial | head -25 > /dev/null \n\t\n\treal 0m2.228s\n\tuser 0m2.216s\n\tsys 0m0.012s\n\n\t// First screenful of regular git log with diffs\n\t[torvalds@g5 linux]$ time git log -p drivers/serial | head -25 > /dev/null \n\t\n\treal 0m0.038s\n\tuser 0m0.036s\n\tsys 0m0.004s\n\nhere you can see how the full \"git log -p\" is obviously more expensive \nthan the full \"git log\" was (the diff generation adds about a second to \nthe full time), but because the diffs are generated incrementally as they \nare shown even with \"--reverse\", the first screenful of the \"--reverse\" \ncase didn't get any more expensive, because we didn't generate all the \ndiffs up-front, just the ones we needed.\n\nAnd the first screenfull of the normal case obviously stays really fast, \nbecause both history generation _and_ diff generation is all on-the-fly.\n\n\t\t\tLinus\n"},{"id":"23573","messageId":"Pine.LNX.4.64.0607101304210.5623@g5.osdl.org","threadId":"4835","inReplyTo":"86mzbhntxu.fsf@blue.stonehenge.com","subject":"Re: git-log to go forward instead of reverse?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-07-10T20:09:57Z","receivedAt":"2006-07-10T20:09:57Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 10 Jul 2006, Randal L. Schwartz wrote:\n>\n> then git-log --pretty=short ORIG_HEAD..HEAD | cat\n\n> The log is just so I can quickly eyeball the interesting changes. The \"cat\"\n> is to keep git-log from starting a pager. (If there's a switch that does\n> *that* that I've overlooked, that'd be good too.)\n\nJust do\n\n\tPAGER= git log --pretty=short ORIG_HEAD..HEAD\n\ninstead.\n\nAnd if you didn't know about \"git shortlog\" already, I personally actually \nfind it easier to read\n\n\tgit log --no-merges ORIG_HEAD.. | git shortlog\n\nwhich orders things by author instead. It also reverses the log messages \nas it does so, so each author will have the one-liners sorted oldest to \nnewest the way you wanted to (so you do _not_ want to pass --reverse to \nthat git-shortlog invocation).\n\n\t\tLinus\n"},{"id":"23574","messageId":"8664i5nrke.fsf@blue.stonehenge.com","threadId":"4835","inReplyTo":"Pine.LNX.4.64.0607101304210.5623@g5.osdl.org","subject":"Re: git-log to go forward instead of reverse?","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-07-10T20:16:49Z","receivedAt":"2006-07-10T20:16:49Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Linus\" == Linus Torvalds writes:\n\nLinus> And if you didn't know about \"git shortlog\" already, I personally actually \nLinus> find it easier to read\n\nLinus> \tgit log --no-merges ORIG_HEAD.. | git shortlog\n\nLinus> which orders things by author instead. It also reverses the log\nLinus> messages as it does so, so each author will have the one-liners sorted\nLinus> oldest to newest the way you wanted to (so you do _not_ want to pass\nLinus> --reverse to that git-shortlog invocation).\n\nSee -- I *knew* there was a shorter way.\n\nLooks like I owe you lunch. (Again? :)\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"23577","messageId":"7vpsgdb40s.fsf@assigned-by-dhcp.cox.net","threadId":"4835","inReplyTo":"86mzbhntxu.fsf@blue.stonehenge.com","subject":"Re: git-log to go forward instead of reverse?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-10T20:26:11Z","receivedAt":"2006-07-10T20:26:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> Well, this is for a \"I'm connected to the net right now: please\n> refresh all of my git mirrors\" script:\n>\n> ## (code here to cd to the right dir omitted)\n> git-fetch\n> if git-status | grep -v 'nothing to commit'\n\ngit-status exits non-zero for \"nothing to commit\" case, so do\nnot grep its output, but check the status of the command, to see\nif your tree is in a good shape to do a pull.\n\n> then echo UPDATE SKIPPED\n> else\n> if git-pull . origin | egrep -v 'up-to-date'\n> then git-log --pretty=short ORIG_HEAD..HEAD | cat\n> fi\n> fi\n>\n> The log is just so I can quickly eyeball the interesting changes.\n\nDo we not leave ORIG_HEAD when we are already up-to-date? If so\nthat would be confusing... No, we do leave ORIG_HEAD no matter\nwhat, so you do not have to have this inner if to grep\nup-to-date (on the other hand, you might want to do intelligent\nthings when git-pull fails). So just drop the if and say\nsomething like:\n\n\telse\n \tPAGER= ; export PAGER\n git pull . origin &&\n git log --pretty ORIG_HEAD..HEAD |\n git shortlog\n\tfi\n\n> The \"cat\"\n> is to keep git-log from starting a pager. (If there's a switch that does\n> *that* that I've overlooked, that'd be good too.)\n\nBTW,\n\n PAGER=cat\n export PAGER\n\nThis should work as more efficiently -- see pager.c ;-)\n"},{"id":"23579","messageId":"861wstnqwd.fsf@blue.stonehenge.com","threadId":"4835","inReplyTo":"7vpsgdb40s.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-log to go forward instead of reverse?","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2006-07-10T20:31:14Z","receivedAt":"2006-07-10T20:31:14Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Junio\" == Junio C Hamano writes:\n\n>> ## (code here to cd to the right dir omitted)\n>> git-fetch\n>> if git-status | grep -v 'nothing to commit'\n\nJunio> git-status exits non-zero for \"nothing to commit\" case, so do\nJunio> not grep its output, but check the status of the command, to see\nJunio> if your tree is in a good shape to do a pull.\n\nNo, this is deliberate. I want to see nothing if we're up to date, but if\nnot, I want to see *everything else* that git-status said. This nice \"grep\n-v\" does precisely the right thing.\n\nJunio> Do we not leave ORIG_HEAD when we are already up-to-date? If so\nJunio> that would be confusing... No, we do leave ORIG_HEAD no matter\nJunio> what, so you do not have to have this inner if to grep\nJunio> up-to-date (on the other hand, you might want to do intelligent\nJunio> things when git-pull fails). So just drop the if and say\nJunio> something like:\n\nJunio> \telse\nJunio> \tPAGER= ; export PAGER\nJunio> git pull . origin &&\nJunio> git log --pretty ORIG_HEAD..HEAD |\nJunio> git shortlog\nJunio> \tfi\n\nHowever, this is good to know.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"23587","messageId":"7vpsgd9lso.fsf@assigned-by-dhcp.cox.net","threadId":"4835","inReplyTo":"Pine.LNX.4.64.0607101304210.5623@g5.osdl.org","subject":"Re: git-log to go forward instead of reverse?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-07-10T21:45:11Z","receivedAt":"2006-07-10T21:45:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> And if you didn't know about \"git shortlog\" already, I personally actually \n> find it easier to read\n>\n> \tgit log --no-merges ORIG_HEAD.. | git shortlog\n>\n> which orders things by author instead.\n\nYes, and you can even have '-p' between git and shortlog in the\nlatter command if you do want the pager ;-).\n\nBTW, when I prepare the \"What's in\" messages, I often find it\nmore useful to have a brother of short-log command that does not\ngroup by author but group by topic branch the commits came from.\n\nCurrently I prepare the categorized list by hand, reviewing each\ncommit in \"master..next\" shortlog output. While I do not mind\nit too much since that is a good way to remind myself what are\nstill cooking, it would be nice to have to a command that takes:\n\n\t- which branch the output is relative to (defaults\n to \"master\");\n\n\t- list of branches that are \"topics\";\n\n - which branch the parts of topics have been merged to\n (optional -- I'd use \"next\" for my use).\n\nand for each topic:\n\n\t- see if the topic branches off from another topic (for\n example, the merge-tree topic branches off from the\n xdiff-common topic like [*1*]); if so, state that and\n use that branch point instead of \"master\" in the next\n step;\n\n\t- list commits that have not made \"master\" yet;\n optionally, when \"next\" is given, limit the output\n only to the ones that have made \"next\" already.\n\n\n[Footnote]\n\n*1*\n\n$ git show-branch --topics master lt/xdiff-common lt/merge-tree\n* [master] git-rev-list: add documentation for --parents, --no-merges\n ! [lt/xdiff-common] xdiff: generate \"anti-diffs\" aka what is common...\n ! [lt/merge-tree] Improved three-way blob merging code\n---\n + [lt/merge-tree] Improved three-way blob merging code\n + [lt/merge-tree^] Prepare \"git-merge-tree\" for future work\n ++ [lt/xdiff-common] xdiff: generate \"anti-diffs\" aka what is common...\n*++ [master~67] checkout -m: fix read-tree invocation\n"}]}