Hi, On Fri, 19 Jan 2007, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > Hi, > > > > On Thu, 18 Jan 2007, Simon 'corecode' Schubert wrote: > > > >> Johannes Schindelin wrote: > >> > On Thu, 18 Jan 2007, Simon 'corecode' Schubert wrote: > >> > > >> > > for cmt in `git-rev-list --no-merges "$upstream"..ORIG_HEAD \ > >> > > - | @@PERL@@ -e 'print reverse <>'` > >> > > + | sed -ne '1!G;$p;h'` > >> > > >> > Why not teach the revision machinery to output in reverse with "--reverse"? > >> > >> I'm more in favour of "small is beautiful". Also from looking at the code, > >> this seems to be a bit complicated. > > > > I'm more in favour of "less shell dependecy is beautiful". And from what I > > can tell, it should be relatively easy: > > > > --- > > > > 14 insertions and 11 deletions stem from moving (and extern'ing) > > reverse_commit_list() from merge-recursive.c to commit.c > > > > So the change is actually 9 insertions and one deletion. > > I think this is sane but I hate to having to worry about > possible fallouts from giving --reverse in setup_revisions() to > make it available to everybody. E.g. things like "what happens > when you say "git format-patch --reverse HEAD~3". It would 1) traverse all commits, storing them in a commit_list, 2) reverse the commits, and then 3) continue as before. So I don't really see a problem (after all, you don't have to use it if you don't want to). It would need a little longer to start up, since all the commits have to be traversed first, but this is inevitable if you want to show the last commit first. > Nevertheless, moving reverse_commit_list out of merge-recursive is a > good clean-up. Not unless we actually use it elsewhere. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html