{"thread":{"id":"6423","subject":"Re: [PATCH] Lose perl dependency. (fwd)","startedAt":"2007-01-18T10:49:49Z","lastAt":"2007-01-23T23:48:21Z","messageCount":31,"participants":["Johannes Schindelin","Simon 'corecode' Schubert","Andy Parkins","Junio C Hamano","Robin Rosenberg","Bill Lear","David Kågedal","Krzysztof Halasa","Randal L. Schwartz"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"31960","messageId":"Pine.LNX.4.63.0701181149260.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6423","inReplyTo":null,"subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-18T10:49:49Z","receivedAt":"2007-01-18T10:49:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Forwarded, since I forgot to add the list\n\n---------- Forwarded message ----------\nDate: Thu, 18 Jan 2007 11:46:05 +0100 (CET)\nFrom: Johannes Schindelin \nTo: Simon 'corecode' Schubert \nSubject: Re: [PATCH] Lose perl dependency.\n\nHi,\n\nOn Thu, 18 Jan 2007, Simon 'corecode' Schubert wrote:\n\n> for cmt in `git-rev-list --no-merges \"$upstream\"..ORIG_HEAD \\\n> -\t\t\t| @@PERL@@ -e 'print reverse <>'`\n> +\t\t\t| sed -ne '1!G;$p;h'`\n\nWhy not teach the revision machinery to output in reverse with \n\"--reverse\"?\n\nCiao,\nDscho\n"},{"id":"31964","messageId":"45AF5F83.6090207@fs.ei.tum.de","threadId":"6423","inReplyTo":"Pine.LNX.4.63.0701181149260.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-01-18T11:52:35Z","receivedAt":"2007-01-18T11:52:35Z","isPatch":true,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> On Thu, 18 Jan 2007, Simon 'corecode' Schubert wrote:\n> \n>> for cmt in `git-rev-list --no-merges \"$upstream\"..ORIG_HEAD \\\n>> -\t\t\t| @@PERL@@ -e 'print reverse <>'`\n>> +\t\t\t| sed -ne '1!G;$p;h'`\n> \n> Why not teach the revision machinery to output in reverse with \n> \"--reverse\"?\n\nI'm more in favour of \"small is beautiful\". Also from looking at the code, this seems to be a bit complicated.\n\ncheers\n simon\n\n-- \nServe - BSD +++ RENT this banner advert +++ ASCII Ribbon /\"\\\nWork - Mac +++ space for low €€€ NOW!1 +++ Campaign \\ /\nParty Enjoy Relax | http://dragonflybsd.org Against HTML \\\nDude 2c 2 the max ! http://golden-apple.biz Mail + News / \\\n\n"},{"id":"31972","messageId":"Pine.LNX.4.63.0701181441010.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6423","inReplyTo":"45AF5F83.6090207@fs.ei.tum.de","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-18T13:57:15Z","receivedAt":"2007-01-18T13:57:15Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Jan 2007, Simon 'corecode' Schubert wrote:\n\n> Johannes Schindelin wrote:\n> > On Thu, 18 Jan 2007, Simon 'corecode' Schubert wrote:\n> > \n> > > for cmt in `git-rev-list --no-merges \"$upstream\"..ORIG_HEAD \\\n> > > -\t\t\t| @@PERL@@ -e 'print reverse <>'`\n> > > +\t\t\t| sed -ne '1!G;$p;h'`\n> > \n> > Why not teach the revision machinery to output in reverse with \"--reverse\"?\n> \n> I'm more in favour of \"small is beautiful\". Also from looking at the code,\n> this seems to be a bit complicated.\n\nI'm more in favour of \"less shell dependecy is beautiful\". And from what I \ncan tell, it should be relatively easy:\n\n---\n\n\t14 insertions and 11 deletions stem from moving (and extern'ing) \n\treverse_commit_list() from merge-recursive.c to commit.c\n\n\tSo the change is actually 9 insertions and one deletion.\n\n commit.c | 11 +++++++++++\n commit.h | 3 +++\n merge-recursive.c | 11 -----------\n revision.c | 7 +++++++\n revision.h | 3 ++-\n 5 files changed, 23 insertions(+), 12 deletions(-)\n\ndiff --git a/commit.c b/commit.c\nindex f495e2d..2735283 100644\n--- a/commit.c\n+++ b/commit.c\n@@ -1231,3 +1231,14 @@ int in_merge_bases(struct commit *commit, struct commit **reference, int num)\n \t}\n \treturn ret;\n }\n+\n+struct commit_list *reverse_commit_list(struct commit_list *list)\n+{\n+\tstruct commit_list *next = NULL, *current, *backup;\n+\tfor (current = list; current; current = backup) {\n+\t\tbackup = current->next;\n+\t\tcurrent->next = next;\n+\t\tnext = current;\n+\t}\n+\treturn next;\n+}\ndiff --git a/commit.h b/commit.h\nindex b8e6e18..563fe86 100644\n--- a/commit.h\n+++ b/commit.h\n@@ -115,4 +115,7 @@ extern struct commit_list *get_shallow_commits(struct object_array *heads,\n \t\tint depth, int shallow_flag, int not_shallow_flag);\n \n int in_merge_bases(struct commit *, struct commit **, int);\n+\n+extern struct commit_list *reverse_commit_list(struct commit_list *list);\n+\n #endif /* COMMIT_H */\ndiff --git a/merge-recursive.c b/merge-recursive.c\nindex fa320eb..75fec5b 100644\n--- a/merge-recursive.c\n+++ b/merge-recursive.c\n@@ -1162,17 +1162,6 @@ static int merge_trees(struct tree *head,\n \treturn clean;\n }\n \n-static struct commit_list *reverse_commit_list(struct commit_list *list)\n-{\n-\tstruct commit_list *next = NULL, *current, *backup;\n-\tfor (current = list; current; current = backup) {\n-\t\tbackup = current->next;\n-\t\tcurrent->next = next;\n-\t\tnext = current;\n-\t}\n-\treturn next;\n-}\n-\n /*\n * Merge the commits h1 and h2, return the resulting virtual\n * commit object and a flag indicating the cleaness of the merge.\ndiff --git a/revision.c b/revision.c\nindex ebd0250..6dc00ba 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1057,6 +1057,11 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch\n \t\t\t\t\tgit_log_output_encoding = \"\";\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\trevs->limited = 1;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \n \t\t\topts = diff_opt_parse(&revs->diffopt, argv+i, argc-i);\n \t\t\tif (opts > 0) {\n@@ -1155,6 +1160,8 @@ void prepare_revision_walk(struct rev_info *revs)\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 d93481f..3eb1ce4 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -42,7 +42,8 @@ struct rev_info {\n \t\t\tunpacked:1, /* see also ignore_packed below */\n \t\t\tboundary:1,\n \t\t\tleft_right:1,\n-\t\t\tparents:1;\n+\t\t\tparents:1,\n+\t\t\treverse:1;\n \n \t/* Diff flags */\n \tunsigned int\tdiff:1,\n"},{"id":"31973","messageId":"45AF7E41.6060706@fs.ei.tum.de","threadId":"6423","inReplyTo":"Pine.LNX.4.63.0701181441010.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-01-18T14:03:45Z","receivedAt":"2007-01-18T14:03:45Z","isPatch":true,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n>>> Why not teach the revision machinery to output in reverse with \"--reverse\"?\n>> I'm more in favour of \"small is beautiful\". Also from looking at the code,\n>> this seems to be a bit complicated.\n> I'm more in favour of \"less shell dependecy is beautiful\". And from what I \n> can tell, it should be relatively easy:\n\nfair enough. looks good!\n\ncheers\n simon\n\n-- \nServe - BSD +++ RENT this banner advert +++ ASCII Ribbon /\"\\\nWork - Mac +++ space for low €€€ NOW!1 +++ Campaign \\ /\nParty Enjoy Relax | http://dragonflybsd.org Against HTML \\\nDude 2c 2 the max ! http://golden-apple.biz Mail + News / \\\n\n"},{"id":"31983","messageId":"200701181500.17970.andyparkins@gmail.com","threadId":"6423","inReplyTo":"Pine.LNX.4.63.0701181441010.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-01-18T15:00:16Z","receivedAt":"2007-01-18T15:00:16Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 January 18 13:57, Johannes Schindelin wrote:\n\nI think this would be clearer if next were renamed...\n\n> +struct commit_list *reverse_commit_list(struct commit_list *list)\n> +{\n> +\tstruct commit_list *prev = NULL, *current, *backup;\n> +\tfor (current = list; current; current = backup) {\n> +\t\tbackup = current->next;\n> +\t\tcurrent->next = prev;\n> +\t\tprev = current;\n> +\t}\n> +\treturn next;\n> +}\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"31984","messageId":"Pine.LNX.4.63.0701181607580.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6423","inReplyTo":"200701181500.17970.andyparkins@gmail.com","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-18T15:08:14Z","receivedAt":"2007-01-18T15:08:14Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Jan 2007, Andy Parkins wrote:\n\n> I think this would be clearer if next were renamed...\n\nExisting code, no bug, won't touch.\n\nCiao,\nDscho\n"},{"id":"32081","messageId":"7vps9ag58g.fsf@assigned-by-dhcp.cox.net","threadId":"6423","inReplyTo":"Pine.LNX.4.63.0701181441010.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-19T19:56:47Z","receivedAt":"2007-01-19T19:56:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Thu, 18 Jan 2007, Simon 'corecode' Schubert wrote:\n>\n>> Johannes Schindelin wrote:\n>> > On Thu, 18 Jan 2007, Simon 'corecode' Schubert wrote:\n>> > \n>> > > for cmt in `git-rev-list --no-merges \"$upstream\"..ORIG_HEAD \\\n>> > > -\t\t\t| @@PERL@@ -e 'print reverse <>'`\n>> > > +\t\t\t| sed -ne '1!G;$p;h'`\n>> > \n>> > Why not teach the revision machinery to output in reverse with \"--reverse\"?\n>> \n>> I'm more in favour of \"small is beautiful\". Also from looking at the code,\n>> this seems to be a bit complicated.\n>\n> I'm more in favour of \"less shell dependecy is beautiful\". And from what I \n> can tell, it should be relatively easy:\n>\n> ---\n>\n> \t14 insertions and 11 deletions stem from moving (and extern'ing) \n> \treverse_commit_list() from merge-recursive.c to commit.c\n>\n> \tSo the change is actually 9 insertions and one deletion.\n\nI think this is sane but I hate to having to worry about\npossible fallouts from giving --reverse in setup_revisions() to\nmake it available to everybody. E.g. things like \"what happens\nwhen you say \"git format-patch --reverse HEAD~3\".\n\nNevertheless, moving reverse_commit_list out of merge-recursive\nis a good clean-up.\n"},{"id":"32106","messageId":"Pine.LNX.4.63.0701200052210.12889@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6423","inReplyTo":"7vps9ag58g.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-19T23:54:49Z","receivedAt":"2007-01-19T23:54:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Jan 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Hi,\n> >\n> > On Thu, 18 Jan 2007, Simon 'corecode' Schubert wrote:\n> >\n> >> Johannes Schindelin wrote:\n> >> > On Thu, 18 Jan 2007, Simon 'corecode' Schubert wrote:\n> >> > \n> >> > > for cmt in `git-rev-list --no-merges \"$upstream\"..ORIG_HEAD \\\n> >> > > -\t\t\t| @@PERL@@ -e 'print reverse <>'`\n> >> > > +\t\t\t| sed -ne '1!G;$p;h'`\n> >> > \n> >> > Why not teach the revision machinery to output in reverse with \"--reverse\"?\n> >> \n> >> I'm more in favour of \"small is beautiful\". Also from looking at the code,\n> >> this seems to be a bit complicated.\n> >\n> > I'm more in favour of \"less shell dependecy is beautiful\". And from what I \n> > can tell, it should be relatively easy:\n> >\n> > ---\n> >\n> > \t14 insertions and 11 deletions stem from moving (and extern'ing) \n> > \treverse_commit_list() from merge-recursive.c to commit.c\n> >\n> > \tSo the change is actually 9 insertions and one deletion.\n> \n> I think this is sane but I hate to having to worry about\n> possible fallouts from giving --reverse in setup_revisions() to\n> make it available to everybody. E.g. things like \"what happens\n> when you say \"git format-patch --reverse HEAD~3\".\n\nIt would\n\n\t1) traverse all commits, storing them in a commit_list,\n\t2) reverse the commits, and then\n\t3) continue as before.\n\nSo I don't really see a problem (after all, you don't have to use it if \nyou don't want to). It would need a little longer to start up, since all \nthe commits have to be traversed first, but this is inevitable if you want \nto show the last commit first.\n\n> Nevertheless, moving reverse_commit_list out of merge-recursive is a \n> good clean-up.\n\nNot unless we actually use it elsewhere.\n\nCiao,\nDscho\n"},{"id":"32113","messageId":"7vvej2bkn2.fsf@assigned-by-dhcp.cox.net","threadId":"6423","inReplyTo":"Pine.LNX.4.63.0701200052210.12889@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-20T00:35:13Z","receivedAt":"2007-01-20T00:35:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> I think this is sane but I hate to having to worry about\n>> possible fallouts from giving --reverse in setup_revisions() to\n>> make it available to everybody. E.g. things like \"what happens\n>> when you say \"git format-patch --reverse HEAD~3\".\n>\n> It would\n>\n> \t1) traverse all commits, storing them in a commit_list,\n> \t2) reverse the commits, and then\n> \t3) continue as before.\n>\n> So I don't really see a problem (after all, you don't have to use it if \n> you don't want to).\n\nWell, I understand what the code does, but what does the above\nthree steps MEAN to the end users?\n\nIn other words, if it does not make sense for format-patch to\ntake --reverse, maybe we should keep it as an internal option,\njust like git-show is the only user of no-walk. And give option\nparsing for it for only selected commands (like rev-list) where\nit makes sense.\n\nI am sure you can come up with a reason why the above three\nsteps are useful for the end user, and it could turn out to be a\nvery valid reason.\n\nBut format-patch was just one example. I will have to worry\nabout all the users of revision traversal machinery.\n\nThe end result might be \"ok, we have spent quite a lot of time\nand audited every users of revision machinery and for all of\nthem --reverse has some valid use cases.\" and that would be\nwonderful. But the thing is, I hate to having to worry about\nthat right now.\n"},{"id":"32121","messageId":"Pine.LNX.4.63.0701200213020.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6423","inReplyTo":"7vvej2bkn2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-20T01:18:08Z","receivedAt":"2007-01-20T01:18:08Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Jan 2007, Junio C Hamano wrote:\n\n> In other words, if it does not make sense for format-patch to\n> take --reverse, maybe we should keep it as an internal option,\n> just like git-show is the only user of no-walk.\n\nOr we just check in cmd_format_patch() (and possibly other users where \n--reverse does not make sense) for revs->reverse and die() upon it.\n\nOTOH we can expect people _not_ to use --reverse with format-patch when \nthey don't know what it does! I mean, I don't go and use \"ls\" with an \noption I saw in the man page, just because it has a cool ring to it.\n\nCiao,\nDscho\n\nP.S.: Perhaps you should just stop worrying and learn to love --reverse \n;-)\n"},{"id":"32124","messageId":"7vbqkubiir.fsf@assigned-by-dhcp.cox.net","threadId":"6423","inReplyTo":"Pine.LNX.4.63.0701200213020.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-20T01:21:00Z","receivedAt":"2007-01-20T01:21:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> OTOH we can expect people _not_ to use --reverse with format-patch when \n> they don't know what it does! I mean, I don't go and use \"ls\" with an \n> option I saw in the man page, just because it has a cool ring to it.\n>\n> P.S.: Perhaps you should just stop worrying and learn to love --reverse \n\nI usually do not worry, especially while I am running 'next'\nmyself.\n\nIt's just unintended consequences I am worried about by touching\nsomewhere deep in the revision machinery after -rc1.\n"},{"id":"32126","messageId":"Pine.LNX.4.63.0701200230550.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6423","inReplyTo":"7vbqkubiir.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-20T01:31:13Z","receivedAt":"2007-01-20T01:31:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Jan 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > OTOH we can expect people _not_ to use --reverse with format-patch when \n> > they don't know what it does! I mean, I don't go and use \"ls\" with an \n> > option I saw in the man page, just because it has a cool ring to it.\n> >\n> > P.S.: Perhaps you should just stop worrying and learn to love --reverse \n> \n> I usually do not worry, especially while I am running 'next'\n> myself.\n> \n> It's just unintended consequences I am worried about by touching\n> somewhere deep in the revision machinery after -rc1.\n\nI have no problem resending after 1.5.0 if you prefer that.\n\nCiao,\nDscho\n"},{"id":"32137","messageId":"7vfya69xym.fsf@assigned-by-dhcp.cox.net","threadId":"6423","inReplyTo":"Pine.LNX.4.63.0701200213020.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-20T03:30:25Z","receivedAt":"2007-01-20T03:30:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> P.S.: Perhaps you should just stop worrying and learn to love --reverse \n> ;-)\n\nAnother thing to think about is how --reverse should interact\nwith --max-count and --skip (and perhaps --max-age but I am not\nsure about that one).\n\nI think there are two very valid ways. You determine what you\nwould spit out as if there is no --reverse, and then reverse the\nresult, or you do not limit with them to get everthing, reverse\nthe result and do the counting limit on that reversed list.\n\nThe former is probably more efficient (I do not think you would\nneed to artificially make it limited like your patch does if you\ngo this route), while the latter may or may not be more useful\nfor what the end users would want to do.\n\nFor example, \"git log -4\" would show the topmost four commits.\nIf you do the former, \"git log --reverse -4\" would give you the\nsame four but in the chronological order (we usually show in the\nreverse order and --reverse would make it the forward order ;-),\nand you do not need to do the limiting for this. You need to\ncapture them and reverse them yourself anyway, so not having to\nlimit may not be a big deal, though.\n\nIf you do the latter, you would be able to get the first four\ncommits in the chronological order. I do not think that is\nusually of much practical value (although people new to git\nalways seem to ask \"how do I get to the root commit\" at least\nonce), but there may be some valid uses for that kind of\nbehaviour.\n"},{"id":"32139","messageId":"45B1945A.1000400@fs.ei.tum.de","threadId":"6423","inReplyTo":"7vfya69xym.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-01-20T04:02:34Z","receivedAt":"2007-01-20T04:02:34Z","isPatch":true,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> I think there are two very valid ways. You determine what you\n> would spit out as if there is no --reverse, and then reverse the\n> result, or you do not limit with them to get everthing, reverse\n> the result and do the counting limit on that reversed list.\n\nWe were originally coming from replacing a perl -e 'print reverse <>' in git-rebase. So I'd say the former. \n\n> If you do the latter, you would be able to get the first four\n> commits in the chronological order. I do not think that is\n> usually of much practical value (although people new to git\n> always seem to ask \"how do I get to the root commit\" at least\n> once), but there may be some valid uses for that kind of\n> behaviour.\n\nBut I doubt that \"--reverse\" would suggest that.\n\n Commit Ordering\n By default, the commits are shown in reverse chronological order.\n\nso --reverse would mean no-reverse, i.e. forward. well, acceptable :) So if --reverse is an option to influence the output after the commit ordering, it is clearly the former.\n\nI don't think the latter makes much sense, anyways.\n\ncheers\n simon\n\n-- \nServe - BSD +++ RENT this banner advert +++ ASCII Ribbon /\"\\\nWork - Mac +++ space for low €€€ NOW!1 +++ Campaign \\ /\nParty Enjoy Relax | http://dragonflybsd.org Against HTML \\\nDude 2c 2 the max ! http://golden-apple.biz Mail + News / \\\n\n"},{"id":"32142","messageId":"Pine.LNX.4.63.0701201025070.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6423","inReplyTo":"7vfya69xym.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-20T09:28:11Z","receivedAt":"2007-01-20T09:28:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Jan 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > P.S.: Perhaps you should just stop worrying and learn to love --reverse \n> > ;-)\n> \n> Another thing to think about is how --reverse should interact\n> with --max-count and --skip (and perhaps --max-age but I am not\n> sure about that one).\n> \n> I think there are two very valid ways. You determine what you\n> would spit out as if there is no --reverse, and then reverse the\n> result, or you do not limit with them to get everthing, reverse\n> the result and do the counting limit on that reversed list.\n\nEvidently, I did not even think about the latter. And I guess that most \npeople expect the former, too. (Maybe we should make it a flipflop, so \nthat \"--reverse --reverse\" unsets the reverse flag again?\n\n> I do not think you would need to artificially make it limited like your \n> patch does if you go this route\n\nWhy? To see the last commit (which should be output first), I _have_ to \ntraverse them first, before reversing the order. I thought revs->limited \ndoes exactly that -- traverse all commits first. Am I mistaken?\n\nCiao,\nDscho\n"},{"id":"32161","messageId":"7vwt3h7dp6.fsf@assigned-by-dhcp.cox.net","threadId":"6423","inReplyTo":"Pine.LNX.4.63.0701201025070.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-20T18:31:01Z","receivedAt":"2007-01-20T18:31:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> I think there are two very valid ways. You determine what you\n>> would spit out as if there is no --reverse, and then reverse the\n>> result, or you do not limit with them to get everthing, reverse\n>> the result and do the counting limit on that reversed list.\n> ...\n>> I do not think you would need to artificially make it limited like your \n>> patch does if you go this route\n>\n> Why? To see the last commit (which should be output first), I _have_ to \n> traverse them first, before reversing the order. I thought revs->limited \n> does exactly that -- traverse all commits first. Am I mistaken?\n\nI think you are talking about the second semantics; I was\ntalking about the first one. In other words, the one whose\nsemantics of:\n\n\t$ git log --max-count=10 --skip=5 --reverse HEAD\n\nis to first internally run\n\n\t$ git log --max-count=10 --skip=5 HEAD\n\nthen reverse the resulting 10 commits and spit them out.\n\nNow, \"git log --max-count=10 --skip=5\" does not need to call\nlimit_list(). It needs to traverse the usual date-sorted\nrevs->commits for fifteen rounds.\n\nLooking at your patch again,...\n\n@@ -1155,6 +1160,8 @@ void prepare_revision_walk(struct rev_info *revs)\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)\n\nThis makes the code traverse and grab everything and then\nreverse; the later get_revision() -> get_revision_1() loop skips\n5, returns 10 and then finally stops. In other words, this\ngives 10 old commits counting from the 6th oldest one in the\nhistory.\n\nIf we prefer the first semantics, we do not have to traverse and\ngrab everything. That is what I was getting at.\n\nThat is, something like this, with your option parsing change\n(modulo we _might_ want to explicitly mark some of the users\nincompatible), addition of reverse field to struct rev_info,\nmoving reverse_commit_list() to a more public place, but without\nmaking the reverse to imply limited traversal.\n\ndiff --git a/revision.c b/revision.c\nindex f2ddd95..161c4c0 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1274,6 +1274,14 @@ struct commit *get_revision(struct rev_info *revs)\n {\n \tstruct commit *c = NULL;\n \n+\tif (revs->reverse) {\n+\t\t/* we were asked to reverse, but haven't reversed the\n+\t\t * result, yet, so do it here once\n+\t\t */\n+\t\trevs->commits = reverse_commit_list(revs->commits);\n+\t\trevs->reverse = 0;\n+\t}\n+\n \tif (0 < revs->skip_count) {\n \t\twhile ((c = get_revision_1(revs)) != NULL) {\n \t\t\tif (revs->skip_count-- <= 0)\n"},{"id":"32179","messageId":"Pine.LNX.4.63.0701202240210.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6423","inReplyTo":"7vwt3h7dp6.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-20T22:04:02Z","receivedAt":"2007-01-20T22:04:02Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 20 Jan 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> I think there are two very valid ways. You determine what you\n> >> would spit out as if there is no --reverse, and then reverse the\n> >> result, or you do not limit with them to get everthing, reverse\n> >> the result and do the counting limit on that reversed list.\n> > ...\n> >> I do not think you would need to artificially make it limited like your \n> >> patch does if you go this route\n> >\n> > Why? To see the last commit (which should be output first), I _have_ to \n> > traverse them first, before reversing the order. I thought revs->limited \n> > does exactly that -- traverse all commits first. Am I mistaken?\n> \n> I think you are talking about the second semantics; I was\n> talking about the first one. In other words, the one whose\n> semantics of:\n> \n> \t$ git log --max-count=10 --skip=5 --reverse HEAD\n> \n> is to first internally run\n> \n> \t$ git log --max-count=10 --skip=5 HEAD\n> \n> then reverse the resulting 10 commits and spit them out.\n\nThat is exactly what I meant.\n\n> Now, \"git log --max-count=10 --skip=5\" does not need to call\n> limit_list(). It needs to traverse the usual date-sorted\n> revs->commits for fifteen rounds.\n\nYes. But I have to traverse this _first_, before even returning a commit \nfrom get_revision().\n\nI had the impression that limit_list() traversed all commits. But I am \nprobably wrong, ain't I?\n\n> @@ -1155,6 +1160,8 @@ void prepare_revision_walk(struct rev_info *revs)\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)\n> \n> This makes the code traverse and grab everything and then\n> reverse; the later get_revision() -> get_revision_1() loop skips\n> 5, returns 10 and then finally stops. In other words, this\n> gives 10 old commits counting from the 6th oldest one in the\n> history.\n\nOkay, I thought that limit_list() honours --skip and --max-count. Looking \nat the code it seems to me that this assumption is wrong.\n\n> If we prefer the first semantics, we do not have to traverse and\n> grab everything. That is what I was getting at.\n> \n> That is, something like this, with your option parsing change\n> (modulo we _might_ want to explicitly mark some of the users\n> incompatible), addition of reverse field to struct rev_info,\n> moving reverse_commit_list() to a more public place, but without\n> making the reverse to imply limited traversal.\n> \n> diff --git a/revision.c b/revision.c\n> index f2ddd95..161c4c0 100644\n> --- a/revision.c\n> +++ b/revision.c\n> @@ -1274,6 +1274,14 @@ struct commit *get_revision(struct rev_info *revs)\n> {\n> \tstruct commit *c = NULL;\n> \n> +\tif (revs->reverse) {\n> +\t\t/* we were asked to reverse, but haven't reversed the\n> +\t\t * result, yet, so do it here once\n> +\t\t */\n> +\t\trevs->commits = reverse_commit_list(revs->commits);\n> +\t\trevs->reverse = 0;\n> +\t}\n> +\n> \tif (0 < revs->skip_count) {\n> \t\twhile ((c = get_revision_1(revs)) != NULL) {\n> \t\t\tif (revs->skip_count-- <= 0)\n\nBut that would not work, would it?\n\nExample:\n\nA - B - C - D\n\nD is the HEAD. Now, when we do not limit_list(), when we get into \nget_revision() for the first time, revs->commits contains _only_ D (we do \nthe ancestry walk on-the-fly). So, your code would \"reverse\" the list \ncontaining only D, reset the reverse flag. In effect, it would do exactly \nthe same as without --reverse.\n\nWhat I _wanted_, was to walk the ancestry chain first, then just reverse \nthe commits, and be done. However, it seems I was utterly mistaken in my \napproach. This should work better:\n\n---\n[PATCH] Teach revision machinery about --reverse\n\nThe option --reverse reverses the order of the commits.\n\nSigned-off-by: Johannes Schindelin \n\n---\n\n Documentation/git-rev-list.txt | 5 +++++\n revision.c | 25 +++++++++++++++++++++++++\n revision.h | 3 ++-\n 3 files changed, 32 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt\nindex 86c94e7..6bb9f51 100644\n--- a/Documentation/git-rev-list.txt\n+++ b/Documentation/git-rev-list.txt\n@@ -27,6 +27,7 @@ SYNOPSIS\n \t [ \\--pretty | \\--header ]\n \t [ \\--bisect ]\n \t [ \\--merge ]\n+\t [ \\--reverse ]\n \t ... [ \\-- ... ]\n \n DESCRIPTION\n@@ -249,6 +250,10 @@ By default, the commits are shown in reverse chronological order.\n \tparent comes before all of its children, but otherwise things\n \tare still ordered in the commit timestamp order.\n \n+--reverse::\n+\n+\tOutput the commits in reverse order.\n+\n Object Traversal\n ~~~~~~~~~~~~~~~~\n \ndiff --git a/revision.c b/revision.c\nindex ebd0250..afc824c 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1057,6 +1057,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch\n \t\t\t\t\tgit_log_output_encoding = \"\";\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 \n \t\t\topts = diff_opt_parse(&revs->diffopt, argv+i, argc-i);\n \t\t\tif (opts > 0) {\n@@ -1285,6 +1289,27 @@ struct commit *get_revision(struct rev_info *revs)\n {\n \tstruct commit *c = NULL;\n \n+\tif (revs->reverse) {\n+\t\tstruct commit_list *list;\n+\n+\t\tif (revs->reverse == 1) {\n+\t\t\trevs->reverse = 0;\n+\t\t\tlist = NULL;\n+\t\t\twhile ((c = get_revision(revs)))\n+\t\t\t\tcommit_list_insert(c, &list);\n+\t\t\trevs->commits = list;\n+\t\t\trevs->reverse = 2;\n+\t\t}\n+\n+\t\tif (!revs->commits)\n+\t\t\treturn NULL;\n+\t\tc = revs->commits->item;\n+\t\tlist = revs->commits->next;\n+\t\tfree(revs->commits);\n+\t\trevs->commits = list;\n+\t\treturn c;\n+\t}\n+\n \tif (0 < revs->skip_count) {\n \t\twhile ((c = get_revision_1(revs)) != NULL) {\n \t\t\tif (revs->skip_count-- <= 0)\ndiff --git a/revision.h b/revision.h\nindex d93481f..5fec184 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -42,7 +42,8 @@ struct rev_info {\n \t\t\tunpacked:1, /* see also ignore_packed below */\n \t\t\tboundary:1,\n \t\t\tleft_right:1,\n-\t\t\tparents:1;\n+\t\t\tparents:1,\n+\t\t\treverse:2;\n \n \t/* Diff flags */\n \tunsigned int\tdiff:1,\n"},{"id":"32180","messageId":"200701210137.41219.robin.rosenberg.lists@dewire.com","threadId":"6423","inReplyTo":"Pine.LNX.4.63.0701202240210.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-01-21T00:37:40Z","receivedAt":"2007-01-21T00:37:40Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"lördag 20 januari 2007 23:04 skrev Johannes Schindelin:\n> +--reverse::\n> +\n> +\tOutput the commits in reverse order.\n> +\n\nThe --reverse is really bad naming since the default *is* to list commits in \nreverse order. Name it \"--chronological\" or something to indicate that you do \nnot want the default reverse order. \n\nSome suggestions:\n\t--chronological\n\t--forward\n\t--noreverse\n\t--commit-order\n\n-- robin\n"},{"id":"32184","messageId":"Pine.LNX.4.63.0701210234350.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6423","inReplyTo":"200701210137.41219.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-21T01:39:59Z","receivedAt":"2007-01-21T01:39:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Jan 2007, Robin Rosenberg wrote:\n\n> lördag 20 januari 2007 23:04 skrev Johannes Schindelin:\n> > +--reverse::\n> > +\n> > +\tOutput the commits in reverse order.\n> > +\n> \n> The --reverse is really bad naming since the default *is* to list \n> commits in reverse order.\n\nEasy. In my worldview it is _not_ the reverse order. It is the most \nuseful order, and thus straight-forward.\n\n> Name it \"--chronological\" or something to indicate that you do not want \n> the default reverse order.\n\nBut it is not chronological. Take for example \"git log --topo-order \n--reverse\". See? Not chronological. Not even reverse chronological.\n\n> Some suggestions:\n> \t--chronological\n> \t--forward\n> \t--noreverse\n> \t--commit-order\n\nAll of these have a high \"Huh?\" effect on me. \"forward\" is wrong, \n\"noreverse\" is confusing at best, and commit-order is anything but \nobvious. IOW those names don't solve a problem.\n\nCiao,\nDscho\n"},{"id":"32185","messageId":"17842.53449.35322.514320@lisa.zopyra.com","threadId":"6423","inReplyTo":"Pine.LNX.4.63.0701210234350.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-01-21T02:32:41Z","receivedAt":"2007-01-21T02:32:41Z","isPatch":true,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"How about a '--order' switch?\n\n --order=chrono[logical]\n --order=rev[erse][-chrono[logical]] (default)\n\nThe switches \"--reverse\" and \"--noreverse\" are certainly confusing in\nthe context of a default that is \"reverse chronological order\".\n\nBTW, my mailer is defaulting to sending mail to the original poster,\nCCing others, including the mailing list. I'm used to simply replying\nto the list. Is this the proper convention here, to reply directly to\nhumans and CC the list?\n\n\nBill\n\nOn Sunday, January 21, 2007 at 02:39:59 (+0100) Johannes Schindelin writes:\n>Hi,\n>\n>On Sun, 21 Jan 2007, Robin Rosenberg wrote:\n>\n>> lördag 20 januari 2007 23:04 skrev Johannes Schindelin:\n>> > +--reverse::\n>> > +\n>> > +\tOutput the commits in reverse order.\n>> > +\n>> \n>> The --reverse is really bad naming since the default *is* to list \n>> commits in reverse order.\n>\n>Easy. In my worldview it is _not_ the reverse order. It is the most \n>useful order, and thus straight-forward.\n>\n>> Name it \"--chronological\" or something to indicate that you do not want \n>> the default reverse order.\n>\n>But it is not chronological. Take for example \"git log --topo-order \n>--reverse\". See? Not chronological. Not even reverse chronological.\n>\n>> Some suggestions:\n>> \t--chronological\n>> \t--forward\n>> \t--noreverse\n>> \t--commit-order\n>\n>All of these have a high \"Huh?\" effect on me. \"forward\" is wrong, \n>\"noreverse\" is confusing at best, and commit-order is anything but \n>obvious. IOW those names don't solve a problem.\n>\n>Ciao,\n>Dscho\n"},{"id":"32187","messageId":"45B2D651.7010606@fs.ei.tum.de","threadId":"6423","inReplyTo":"Pine.LNX.4.63.0701202240210.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-01-21T02:56:17Z","receivedAt":"2007-01-21T02:56:17Z","isPatch":true,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> @@ -1285,6 +1289,27 @@ struct commit *get_revision(struct rev_info *revs)\n> {\n> \tstruct commit *c = NULL;\n> \n> +\tif (revs->reverse) {\n> +\t\tstruct commit_list *list;\n> +\n> +\t\tif (revs->reverse == 1) {\n> +\t\t\trevs->reverse = 0;\n> +\t\t\tlist = NULL;\n> +\t\t\twhile ((c = get_revision(revs)))\n> +\t\t\t\tcommit_list_insert(c, &list);\n> +\t\t\trevs->commits = list;\n> +\t\t\trevs->reverse = 2;\n> +\t\t}\n> +\n> +\t\tif (!revs->commits)\n> +\t\t\treturn NULL;\n> +\t\tc = revs->commits->item;\n> +\t\tlist = revs->commits->next;\n> +\t\tfree(revs->commits);\n> +\t\trevs->commits = list;\n> +\t\treturn c;\n> +\t}\n> +\n> \tif (0 < revs->skip_count) {\n> \t\twhile ((c = get_revision_1(revs)) != NULL) {\n> \t\t\tif (revs->skip_count-- <= 0)\n> diff --git a/revision.h b/revision.h\n> index d93481f..5fec184 100644\n> --- a/revision.h\n> +++ b/revision.h\n> @@ -42,7 +42,8 @@ struct rev_info {\n> \t\t\tunpacked:1, /* see also ignore_packed below */\n> \t\t\tboundary:1,\n> \t\t\tleft_right:1,\n> -\t\t\tparents:1;\n> +\t\t\tparents:1,\n> +\t\t\treverse:2;\n> \n> \t/* Diff flags */\n> \tunsigned int\tdiff:1,\n\nI like this. However, rev_info.reverse needs some documentation. Or the block in get_revision does:\n\n/*\n * rev_info.reverse is used to note the fact that we want to output the list\n * of revisions in reverse order. To accomplish this goal, reverse can have\n * different values:\n * 0 do nothing\n * 1 reverse the list\n * 2 internal use: we have already obtained and reversed the list,\n * now we only need to yield its items.\n */\n\ncheers\n simon\n\n-- \nServe - BSD +++ RENT this banner advert +++ ASCII Ribbon /\"\\\nWork - Mac +++ space for low €€€ NOW!1 +++ Campaign \\ /\nParty Enjoy Relax | http://dragonflybsd.org Against HTML \\\nDude 2c 2 the max ! http://golden-apple.biz Mail + News / \\\n\n"},{"id":"32188","messageId":"7vr6tp5aqq.fsf@assigned-by-dhcp.cox.net","threadId":"6423","inReplyTo":"17842.53449.35322.514320@lisa.zopyra.com","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-21T03:17:49Z","receivedAt":"2007-01-21T03:17:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bill Lear writes:\n\n> How about a '--order' switch?\n>\n> --order=chrono[logical]\n> --order=rev[erse][-chrono[logical]] (default)\n>\n> The switches \"--reverse\" and \"--noreverse\" are certainly confusing in\n> the context of a default that is \"reverse chronological order\".\n\nI think --reverse is just fine. It is \"reverse\" from usual, and\npeople already know (or they should learn) what the usual order\nis.\n\n> BTW, my mailer is defaulting to sending mail to the original poster,\n> CCing others, including the mailing list. I'm used to simply replying\n> to the list. Is this the proper convention here, to reply directly to\n> humans and CC the list?\n\nI only speak for myself, but I always prefer to address my\nmessage's To: header to the person I am primarily talking to,\nwhile leaving other people on Cc: line (which usually includes\nthe list address).\n"},{"id":"32201","messageId":"Pine.LNX.4.63.0701211154320.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6423","inReplyTo":"45B2D651.7010606@fs.ei.tum.de","subject":"[PATCH] Teach revision machinery about --reverse","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-21T11:19:10Z","receivedAt":"2007-01-21T11:19:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nThe option --reverse reverses the order of the commits.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Sun, 21 Jan 2007, Simon 'corecode' Schubert wrote:\n\t\n\t> > [the --reverse patch]\n\t\n\tPlease do not quote parts of the mail you don't really refer to.\n\t\n\t> I like this. However, rev_info.reverse needs some \n\t> documentation. Or the block in get_revision does:\n\t> \n\t> /*\n\t> * rev_info.reverse is used to note the fact that we want to output the list\n\t> * of revisions in reverse order. To accomplish this goal, reverse can have\n\t> * different values:\n\t> * 0 do nothing\n\t> * 1 reverse the list\n\t> * 2 internal use: we have already obtained and reversed the list,\n\t> * now we only need to yield its items.\n\t> */\n\t\n\tI liked the comment in get_revision() better.\n\t\n\tBut then an idea just hit me: it might make sense to introduce \n\tanother flag instead, \"no_walk\", which says that revs->commits \n\tshould be walked as is, not walking parents.\n\t\n\tAnd then I saw it already exists. D'oh.\n\n Documentation/git-rev-list.txt | 5 +++++\n revision.c | 20 ++++++++++++++++++++\n revision.h | 3 ++-\n 3 files changed, 27 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt\nindex 86c94e7..6bb9f51 100644\n--- a/Documentation/git-rev-list.txt\n+++ b/Documentation/git-rev-list.txt\n@@ -27,6 +27,7 @@ SYNOPSIS\n \t [ \\--pretty | \\--header ]\n \t [ \\--bisect ]\n \t [ \\--merge ]\n+\t [ \\--reverse ]\n \t ... [ \\-- ... ]\n \n DESCRIPTION\n@@ -249,6 +250,10 @@ By default, the commits are shown in reverse chronological order.\n \tparent comes before all of its children, but otherwise things\n \tare still ordered in the commit timestamp order.\n \n+--reverse::\n+\n+\tOutput the commits in reverse order.\n+\n Object Traversal\n ~~~~~~~~~~~~~~~~\n \ndiff --git a/revision.c b/revision.c\nindex ebd0250..6d512ff 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1057,6 +1057,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch\n \t\t\t\t\tgit_log_output_encoding = \"\";\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 \n \t\t\topts = diff_opt_parse(&revs->diffopt, argv+i, argc-i);\n \t\t\tif (opts > 0) {\n@@ -1285,6 +1289,22 @@ struct commit *get_revision(struct rev_info *revs)\n {\n \tstruct commit *c = NULL;\n \n+\tif (revs->reverse) {\n+\t\tstruct commit_list *list;\n+\n+\t\trevs->reverse = 0;\n+\t\tlist = NULL;\n+\t\twhile ((c = get_revision(revs)))\n+\t\t\tcommit_list_insert(c, &list);\n+\t\trevs->commits = list;\n+\t\trevs->no_walk = 1;\n+\t\t/* reset flags */\n+\t\twhile (list) {\n+\t\t\tlist->item->object.flags &= ~(ADDED | SEEN | SHOWN);\n+\t\t\tlist = list->next;\n+\t\t}\n+\t}\n+\n \tif (0 < revs->skip_count) {\n \t\twhile ((c = get_revision_1(revs)) != NULL) {\n \t\t\tif (revs->skip_count-- <= 0)\ndiff --git a/revision.h b/revision.h\nindex d93481f..3eb1ce4 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -42,7 +42,8 @@ struct rev_info {\n \t\t\tunpacked:1, /* see also ignore_packed below */\n \t\t\tboundary:1,\n \t\t\tleft_right:1,\n-\t\t\tparents:1;\n+\t\t\tparents:1,\n+\t\t\treverse:1;\n \n \t/* Diff flags */\n \tunsigned int\tdiff:1,\n-- \n1.5.0.rc1.g956c1-dirty\n"},{"id":"32234","messageId":"87vej0gh4k.fsf@morpheus.local","threadId":"6423","inReplyTo":"7vr6tp5aqq.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-01-21T22:16:43Z","receivedAt":"2007-01-21T22:16:43Z","isPatch":true,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Junio C Hamano writes:\n\n> Bill Lear writes:\n>\n>> How about a '--order' switch?\n>>\n>> --order=chrono[logical]\n>> --order=rev[erse][-chrono[logical]] (default)\n>>\n>> The switches \"--reverse\" and \"--noreverse\" are certainly confusing in\n>> the context of a default that is \"reverse chronological order\".\n>\n> I think --reverse is just fine. It is \"reverse\" from usual, and\n> people already know (or they should learn) what the usual order\n> is.\n>\n>> BTW, my mailer is defaulting to sending mail to the original poster,\n>> CCing others, including the mailing list. I'm used to simply replying\n>> to the list. Is this the proper convention here, to reply directly to\n>> humans and CC the list?\n>\n> I only speak for myself, but I always prefer to address my\n> message's To: header to the person I am primarily talking to,\n> while leaving other people on Cc: line (which usually includes\n> the list address).\n\nI, on the other hand, have recently been annoyed by having my inbox\nfilled with mails that I already can read on the list (actually the\ngmane newsgruop). So there is probably not a single good answer.\n\n-- \nDavid Kågedal\n"},{"id":"32236","messageId":"Pine.LNX.4.63.0701212323580.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6423","inReplyTo":"87vej0gh4k.fsf@morpheus.local","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-21T22:35:21Z","receivedAt":"2007-01-21T22:35:21Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 21 Jan 2007, David Kågedal wrote:\n\n> Junio C Hamano writes:\n> \n> > I only speak for myself, but I always prefer to address my message's \n> > To: header to the person I am primarily talking to, while leaving \n> > other people on Cc: line (which usually includes the list address).\n\nI have to agree: if the mail is adressed directly to me, I am much more \nlikely to read it. So I am quite annoyed by answers to my emails, which \ndo not have me in To: or Cc:.\n\n> I, on the other hand, have recently been annoyed by having my inbox \n> filled with mails that I already can read on the list (actually the \n> gmane newsgruop). So there is probably not a single good answer.\n\nWell, RFC 1855 \"Netiquette guidelines\" states in 2.1.2 \"for mail:\":\n\n - Watch cc's when replying. Don't continue to include\n people if the messages have become a 2-way conversation.\n\n(I myself am guilty of not culling people when no longer quoting them.)\n\nThe statement from the RFC obviously assumes that you reply to the author \nof the message (and since it came from a mailing list, if it is of \ninterest to the list, you should Cc: that, too).\n\nIMHO it is all to easy to filter duplicate messages, and generally not \npossible to identify replies to _your_ mails when the reply is not sent to \n_you_, but to the list.\n\nIOW I agree with Junio.\n\nCiao,\nDscho\n"},{"id":"32395","messageId":"m3zm89zxs1.fsf@maximus.localdomain","threadId":"6423","inReplyTo":"87vej0gh4k.fsf@morpheus.local","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Krzysztof Halasa","fromEmail":"khc@pm.waw.pl","sentAt":"2007-01-23T13:18:54Z","receivedAt":"2007-01-23T13:18:54Z","isPatch":true,"sender":{"key":"khc@pm.waw.pl","avatar":null},"body":"David Kågedal writes:\n\n> I, on the other hand, have recently been annoyed by having my inbox\n> filled with mails that I already can read on the list (actually the\n> gmane newsgruop). So there is probably not a single good answer.\n\nActually there is, you can put Reply-To: in your messages.\n-- \nKrzysztof Halasa\n"},{"id":"32400","messageId":"873b6197jf.fsf@morpheus.local","threadId":"6423","inReplyTo":"m3zm89zxs1.fsf@maximus.localdomain","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-01-23T13:50:12Z","receivedAt":"2007-01-23T13:50:12Z","isPatch":true,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Krzysztof Halasa writes:\n\n> David Kågedal writes:\n>\n>> I, on the other hand, have recently been annoyed by having my inbox\n>> filled with mails that I already can read on the list (actually the\n>> gmane newsgruop). So there is probably not a single good answer.\n>\n> Actually there is, you can put Reply-To: in your messages.\n\nThat is never the correct answer. If peaple want to reply to me, they\nshould be able to. If they want to follow-up to the list, they should\nbe able to. I can not decide in advance for them what they want to\ndo.\n\n-- \nDavid Kågedal\n"},{"id":"32409","messageId":"m3irexzua9.fsf@maximus.localdomain","threadId":"6423","inReplyTo":"873b6197jf.fsf@morpheus.local","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Krzysztof Halasa","fromEmail":"khc@pm.waw.pl","sentAt":"2007-01-23T14:34:22Z","receivedAt":"2007-01-23T14:34:22Z","isPatch":true,"sender":{"key":"khc@pm.waw.pl","avatar":null},"body":"David Kågedal writes:\n\n>> Actually there is, you can put Reply-To: in your messages.\n>\n> That is never the correct answer. If peaple want to reply to me, they\n> should be able to. If they want to follow-up to the list, they should\n> be able to. I can not decide in advance for them what they want to\n> do.\n\nActually it is the correct way to do that. If people \"reply to group\"\nor whatever is it called, the reply goes to \"Reply-To\" list.\nIf they \"reply to author\", the reply goes to \"From\" address and\n\"Reply-To\" is ignored.\n-- \nKrzysztof Halasa\n"},{"id":"32433","messageId":"86bqkp1xkz.fsf@blue.stonehenge.com","threadId":"6423","inReplyTo":"m3irexzua9.fsf@maximus.localdomain","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-01-23T17:07:08Z","receivedAt":"2007-01-23T17:07:08Z","isPatch":true,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Krzysztof\" == Krzysztof Halasa writes:\n\nKrzysztof> Actually it is the correct way to do that. If people \"reply to group\"\nKrzysztof> or whatever is it called, the reply goes to \"Reply-To\" list.\nKrzysztof> If they \"reply to author\", the reply goes to \"From\" address and\nKrzysztof> \"Reply-To\" is ignored.\n\nArgh. Such misinformation abounds on this topic!\n\nThe only reason a mail client has the ability to ignore the \"reply-to\"\n(which *violates* the RFCs - go check it out) is because of *broken*\n(but perhaps well-intentioned) mailing lists that add \"reply-to: list\".\n\nThe proper solution is to *follow* the RFCs, and leave the reply-to alone when\nrelaying. If someone wants to reply to the list *and* the person, they can\nreply to both the \"from (or reply-to)\" and \"to\" addresses, often called a\n\"wide reply\". If someone wants to reply to just the person, they use the\n\"reply-to\" if it's present, or the \"from\" if not. This is *proper* behavior:\nit's only some broken mailing lists out there that have caused us to have to\nwork around it.\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":"32462","messageId":"m34pqh2uiu.fsf@maximus.localdomain","threadId":"6423","inReplyTo":"86bqkp1xkz.fsf@blue.stonehenge.com","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Krzysztof Halasa","fromEmail":"khc@pm.waw.pl","sentAt":"2007-01-23T23:27:53Z","receivedAt":"2007-01-23T23:27:53Z","isPatch":true,"sender":{"key":"khc@pm.waw.pl","avatar":null},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> The proper solution is to *follow* the RFCs,\n\nDo you remember RFC #s by chance? Some details maybe?\n\n> and leave the reply-to alone\n> when\n> relaying. If someone wants to reply to the list *and* the person, they can\n> reply to both the \"from (or reply-to)\" and \"to\" addresses, often called a\n> \"wide reply\". If someone wants to reply to just the person, they use the\n> \"reply-to\" if it's present, or the \"from\" if not. This is *proper* behavior:\n> it's only some broken mailing lists out there that have caused us to have to\n> work around it.\n\nThe list doesn't modify the headers in question, at least as far as lkml\nis concerned, so I assume you mean some other lists that are broken.\n\nReply-To is for the author to set, list software shouldn't change it.\nWhile it's normal to reply to \"From\", \"Cc\" and \"To\" (at least here),\nsome people prefer to be omitted when replying to their mail. How could\nthey do that if not with Reply-To?\n\nThen, if I see lkml and no author's address in Reply-To, how\ncould I contact him/her privately if not writing to \"From\" and\nignoring Reply-To?\n-- \nKrzysztof Halasa\n"},{"id":"32463","messageId":"m3zm891f0a.fsf@maximus.localdomain","threadId":"6423","inReplyTo":"m34pqh2uiu.fsf@maximus.localdomain","subject":"Re: [PATCH] Lose perl dependency. (fwd)","fromName":"Krzysztof Halasa","fromEmail":"khc@pm.waw.pl","sentAt":"2007-01-23T23:48:21Z","receivedAt":"2007-01-23T23:48:21Z","isPatch":true,"sender":{"key":"khc@pm.waw.pl","avatar":null},"body":"> The list doesn't modify the headers in question, at least as far as lkml\n> is concerned\n\n... and git list, too.\n-- \nKrzysztof Halasa\n"}]}