On Sun, 2005-04-17 at 18:15 -0700, Linus Torvalds wrote: > In particular, is there some easy way to walk backwards by time? "git log" > definitely needs that, and merge-base clearly wants something similar.
Actually the ideal output of 'git log' isn't strictly chronological. IIRC my bkexport scripts used to make a chronologically sorted list, and I ended up changing it. Simple example: if there are changesets which have been lurking in some tree for months waiting for you to pull, and the only thing you did since I ran 'git log' on your tree yesterday is pull from that tree, then those changesets are what I want to see at the top of 'git log' output. In fact this probably means that the depth-first tree walking of the original gitlog.sh is probably the right thing to do, but when we hit a merge we want to try to make sure we process the _remote_ parent first. Are we sorting the 'parent' links in merges so that two merges of the same branches are guaranteed to be identical (assuming identical contents otherwise)? Or is it just that we didn't think about it, and so merges are putting the local and remote parents in the 'wrong' order by coincidence? -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
