{"thread":{"id":"960","subject":"git-rev-list problem with --max-age and --merge-order","startedAt":"2005-06-16T12:39:50Z","lastAt":"2005-06-16T16:06:28Z","messageCount":2,"participants":["Paul Mackerras","Jon Seymour"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"4992","messageId":"17073.29462.564422.743677@cargo.ozlabs.ibm.com","threadId":"960","inReplyTo":null,"subject":"git-rev-list problem with --max-age and --merge-order","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2005-06-16T12:39:50Z","receivedAt":"2005-06-16T12:39:50Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"I have a version of gitk that draws stuff more-or-less as it receives\nit from git-rev-list -- it reorders the commits somewhat but it\ndoesn't need to wait for the end of the output from git-rev-list\nbefore it can draw anything.  To do that it passes --merge-order to\ngit-rev-list and relies on the property that parents will be listed\nafter all of their children.\n\nI also want to make the default be to show the commits for the last 30\ndays.  However, using --max-age with --merge-order outputs many fewer\ncommits than I get if I use the same --max-age argument without\n--merge-order.  For example, on the current linux-2.6 git tree,\ngit-rev-tree --max-age=1116330140 HEAD outputs 655 commits, whereas\ngit-rev-tree --merge-order --max-age=1116330140 HEAD only outputs 173\ncommits.  That date is 2005-05-17 21:42:20 in my timezone, about 30\ndays ago.  An example of a commit that isn't output with --merge-order\nis 1e86d1c648508fd50e6c9960576b87906a7906ad:\n\nAuthor: Benjamin Herrenschmidt <benh@kernel.crashing.org>  2005-06-02 14:11:37\nCommitter: Linus Torvalds <torvalds@ppc970.osdl.org>  2005-06-03 01:19:27\n\n[PATCH] ppc64: Fix result code handling in prom_init\n\nAny ideas why using --merge-order means we don't see this one?  It's\ncertainly less than 30 days old.\n\nThanks,\nPaul.\n"},{"id":"4994","messageId":"2cfc4032050616090632f10b2e@mail.gmail.com","threadId":"960","inReplyTo":"2cfc40320506160745411858f1@mail.gmail.com","subject":"Re: git-rev-list problem with --max-age and --merge-order","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-06-16T16:06:28Z","receivedAt":"2005-06-16T16:06:28Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"G'day Paul,\n\nI think I know why this is happening and I think it has a relatively\ntrivial fix, but I need to confirm this tomorrow after the effects of\nseveral schooners of Toohey's Old have worn off.\n\nThe current logic is to stop after one commit is found with an age\ngreater than the maximum age. This doesn't work as expected if a\n\"right\" branch has an \"old\" commit since, by being a right branch,\nthis commit will appear at the start of the merge-order list and the\noutput of any commits in the left branch will be suppressed by this\nlogic.\n\nI think the --merge-order logic should be altered as follows:\n    - stop at the first epoch boundary with an age greater than the maximum age \n      but filter out (from display) any commits older than the maximum\nage prior to that boundary.\n\nThis will still omit commits in the case that either the epoch\nboundary or a commit beyond the epoch boundary have timestamps that\ndon't match the merge order, but that should be a relatively\ninfrequent occurrence.\n\nI'll create a patch for the current Linus HEAD later today.\n\njon.\n"}]}