{"thread":{"id":"773","subject":"git-rev-list: proper lazy reachability","startedAt":"2005-05-31T01:58:37Z","lastAt":"2005-06-04T19:46:26Z","messageCount":16,"participants":["Linus Torvalds","Jon Seymour","Paul Mackerras","Matthias Urlichs","Junio C Hamano","Thomas Glanzmann","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"4288","messageId":"Pine.LNX.4.58.0505301847120.1876@ppc970.osdl.org","threadId":"773","inReplyTo":null,"subject":"git-rev-list: proper lazy reachability","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-31T01:58:37Z","receivedAt":"2005-05-31T01:58:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOk, I just made git-rev-list DTRT when you pass it a \"beginning\" and \n\"end\", ie it does proper reachability analysis _without_ parsing the whole \nset of commits. \n\nIt's probably buggy, so don't get too excited, but it seems to give the \nright results for something like\n\n\tgit-rev-list v2.6.12-rc5 v2.6.12-rc4\n\nwhich is basically \"give me a rev-list of everything that is in rc5 but is \nnot in rc4\".\n\nSo now \"git-rev-list a b\" should be equivalent to \"git-rev-tree a ^b\", \nexcept it's faster, and it doesn't print out anything else.\n\nBecause it doesn't need to go all the way back to the root (only far \nenough back to be able to determine that there can be no more unreachable \nentries), it should be constant-time in the total history size. Doesn't \nmatter if you've got a million revisions, if you asked for the difference \nbetween two \"close\" ones, it will be fast.\n\nSomebody should probably take a look at my simplistic algorithm, since it \ncan probably be improved upon and/or fixed for corner-cases.\n\n\t\tLinus\n"},{"id":"4291","messageId":"2cfc4032050531005820979ca7@mail.gmail.com","threadId":"773","inReplyTo":"Pine.LNX.4.58.0505301847120.1876@ppc970.osdl.org","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-31T07:58:45Z","receivedAt":"2005-05-31T07:58:45Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 5/31/05, Linus Torvalds wrote:\n> \n> Somebody should probably take a look at my simplistic algorithm, since it\n> can probably be improved upon and/or fixed for corner-cases.\n\nSeems reasonable, though I think that in a graph like this:\n\n A \n / | \\ \nB C D\n| / /\nE\n| \\ \nF G\n\nand searching for git-rev-list A ^B\n\nit would actually be better to stop at E (printing A,B,C,D,E), rather\nthan B because the contemporaneously parallel edits C and D and the\ncommon base E are relevant to evaluating B since they got merged with\nB into A from the common starting point E.\n\nIn the lingo of my epoch theory, this is searching to the next nearest\nepoch boundary past B.\n\nMy merge-order patch to rev-list which incorporates epoch theory is\nstill on its way - it turned out that incrementally finding epoch\nboundaries was not quite as simple as I thought it would be. I expect\nI'll have a respectable looking patch available this weekend. The\npatch I have now works quite well for smaller graphs but fails on\nlarger graphs because it relies on rational numbers with large\nnumerators and denominators and these end up overflowing even 64 bit\nintegers. I think I know how to fix it, but it will take me a few more\ndays yet.\n\njon.\n\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"4297","messageId":"17052.21846.816147.370354@cargo.ozlabs.ibm.com","threadId":"773","inReplyTo":"Pine.LNX.4.58.0505301847120.1876@ppc970.osdl.org","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2005-05-31T12:15:18Z","receivedAt":"2005-05-31T12:15:18Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Linus Torvalds writes:\n\n> Ok, I just made git-rev-list DTRT when you pass it a \"beginning\" and \n> \"end\", ie it does proper reachability analysis _without_ parsing the whole \n> set of commits. \n\nI have made gitk use git-rev-list instead of git-rev-tree, but it\nstill absorbs the whole of git-rev-list's output before drawing\nanything. I'd like to make it draw the commit graph and list\nincrementally as it gets the output from git-rev-list, but to do that\nI need to know whether git-rev-list could ever print a commit ID\n*after* one of its parents. If it never does that then I can\nrestructure the code to do the drawing incrementally fairly easily.\n\nPaul.\n"},{"id":"4301","messageId":"Pine.LNX.4.58.0505310730010.1876@ppc970.osdl.org","threadId":"773","inReplyTo":"2cfc4032050531005820979ca7@mail.gmail.com","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-31T14:35:00Z","receivedAt":"2005-05-31T14:35:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 31 May 2005, Jon Seymour wrote:\n>\n> On 5/31/05, Linus Torvalds wrote:\n> > \n> > Somebody should probably take a look at my simplistic algorithm, since it\n> > can probably be improved upon and/or fixed for corner-cases.\n> \n> Seems reasonable, though I think that in a graph like this:\n> \n> A \n> / | \\ \n> B C D\n> | / /\n> E\n> | \\ \n> F G\n> \n> and searching for git-rev-list A ^B it would actually be better to stop\n> at E (printing A,B,C,D,E), rather than B because the contemporaneously\n> parallel edits C and D and the common base E are relevant to evaluating\n> B since they got merged with B into A from the common starting point E.\n\nYou're talking about something else - you worry about showing a graph, for \nexample.\n\nWhat git-rev-list A B does is literally for something like a \"changelog\" -\nwhat commits were added in A that weren't in B, and the list is A, C and\nD. Or, more commonly, used for something like\n\n\tgit-rev-list HEAD v2.6.12-rc5 | git-diff-tree --stdin -v -p drivers/usb\n\nwhich basically says \"what changed since 2.6.12-rc5 in the drivers/usb \ntree\"?\n\nSo in that situation, you really do _not_ want to see B and E, even if\nyou'd need those two to make all the connections. Because you've seen B\nand E already (they were in v2.6.12-rc5), and if you're looking for a bug\nthat didn't happen in that release, you really only want to see the new\nstuff.\n\n\t\tLinus\n"},{"id":"4302","messageId":"Pine.LNX.4.58.0505310735260.1876@ppc970.osdl.org","threadId":"773","inReplyTo":"17052.21846.816147.370354@cargo.ozlabs.ibm.com","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-31T14:39:41Z","receivedAt":"2005-05-31T14:39:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 31 May 2005, Paul Mackerras wrote:\n> \n> I have made gitk use git-rev-list instead of git-rev-tree, but it\n> still absorbs the whole of git-rev-list's output before drawing\n> anything. I'd like to make it draw the commit graph and list\n> incrementally as it gets the output from git-rev-list, but to do that\n> I need to know whether git-rev-list could ever print a commit ID\n> *after* one of its parents. If it never does that then I can\n> restructure the code to do the drawing incrementally fairly easily.\n\nYou should never see a parent before a child from git-rev-list. I may have \nscrewed something up when I move things between the two lists (the \nbefore/after thing needs to first do the reachability thing on one list, \nand then moves them to the \"potential output list\"), but I don't think so.\n\nAnyway, at that point it would be a git-rev-list bug, so if you can make\nyour code notice and complain (\"git-rev-list listed parent before child\") \nrather than silently show crud, that would help debugging it if it ever \nhappened.\n\n\t\tLinus\n"},{"id":"4304","messageId":"Pine.LNX.4.58.0505310758270.1876@ppc970.osdl.org","threadId":"773","inReplyTo":"2cfc4032050531005820979ca7@mail.gmail.com","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-31T15:13:35Z","receivedAt":"2005-05-31T15:13:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 31 May 2005, Jon Seymour wrote:\n> \n> A \n> / | \\ \n> B C D\n> | / /\n> E\n> | \\ \n> F G\n> \n> and searching for git-rev-list A ^B it would actually be better to stop\n> at E (printing A,B,C,D,E)\n\nBtw, you probably looked at the actual code, so you know this, but maybe \nit wasn't clear to everybody else: the code obviously _will_ look at all \nof ABCDE before it can even decide that it should print out ACD, since it \nreally needs to.\n\nWhat happens is that it walks the tree \"time-first\" (not depth-first or \nbreadth-first, but \"most-recent-first\"), which tends to approximate what \nwe want, and when it sees \"B\" it will mark all of its children as \nuninteresting since they were clearly seen. So it will actually have \ngotten all the way to E before it can tell that it has seen enough.\n\nThe thing that makes git-rev-list preferred over git-rev-tree is that it \ncan avoid looking at F and G and older parents, since it's clear by E that \nwalking the tree any further would be pointless, and all the commits we \ncould look at are already marked uninteresting.\n\nBut if somebody wanted to actually show this as a _graph_, what you would \nprobably want is actually all of ABCDE, except you'd get the \"interesting\" \nbit separately (ie ACD would be tagged some way). Then you could show a \nsane graph that is colored by whether something is new or not, for \nexample. That's absolutely trivial to do wiyth the new rev-list algorithm, \nin case somebody really cares - it's literally just changing the printout \nto show the entries marked \"ignored\" with some extra marking.\n\n(Well, slightly more too: you'd have to add the uninteresting commits to\nthe list, and mark the end object itself as being ignored, but that's two\nmore trivial lines. Right now the code knows that it won't even add some \nobjects to the output list, so..).\n\n\t\tLinus\n"},{"id":"4306","messageId":"Pine.LNX.4.58.0505310813540.1876@ppc970.osdl.org","threadId":"773","inReplyTo":"Pine.LNX.4.58.0505310735260.1876@ppc970.osdl.org","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-31T15:23:47Z","receivedAt":"2005-05-31T15:23:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 31 May 2005, Linus Torvalds wrote:\n> \n> You should never see a parent before a child from git-rev-list.\n\nActually, I take that back.\n\nA commit that has several children will see _a_ child before the parent is\nshown, but while the time-based ordering means that it _likely_ will order\nall children before the parent, now that I think about it, that's not\nguaranteed to be true. You could have\n\n\t A\n\t / \\\n\t B |\n\t \\ /\n\t C\n\t |\n\t D\n\nand if C has a date that is before B, then git-rev-list would traverse the\ntree (and show it) in the order A C B.\n\nIn fact, even D might be listed before B is (eg, the person who committed\nB had a clock that was set to the last century, and so the date on that\nwas wrong).\n\nThe thing is, since B has such an \"old\" date, the traversal assumes that\nit is old and very low down in the tree, and that it's better off parsing\nother commits first, so it will never look more closely at B and notice\nthat it has a parent that has already been parsed.\n\nSo I guess you'll have to wait for the end and do the toposort after all. \nSorry about the confusion on my part.\n\n\t\tLinus\n"},{"id":"4333","messageId":"2cfc4032050531171437d5d9eb@mail.gmail.com","threadId":"773","inReplyTo":"Pine.LNX.4.58.0505310758270.1876@ppc970.osdl.org","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-06-01T00:14:19Z","receivedAt":"2005-06-01T00:14:19Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On 6/1/05, Linus Torvalds wrote:\n> \n> \n> On Tue, 31 May 2005, Jon Seymour wrote:\n> >\n> > A\n> > / | \\\n> > B C D\n> > | / /\n> > E\n> > | \\\n> > F G\n> >\n> > and searching for git-rev-list A ^B it would actually be better to stop\n> > at E (printing A,B,C,D,E)\n> \n> Btw, you probably looked at the actual code, so you know this, but maybe\n> it wasn't clear to everybody else: the code obviously _will_ look at all\n> of ABCDE before it can even decide that it should print out ACD, since it\n> really needs to.\n\nI did look at the code and concluded that ACD would be displayed and\nsimply assumed B would also be displayed. Anyway, you are right, for\nthe purposes you are interested in neither B nor E are interesting.\n\n> \n> But if somebody wanted to actually show this as a _graph_, what you would\n> probably want is actually all of ABCDE, except you'd get the \"interesting\"\n> bit separately (ie ACD would be tagged some way). Then you could show a\n> sane graph that is colored by whether something is new or not, for\n> example. That's absolutely trivial to do wiyth the new rev-list algorithm,\n> in case somebody really cares - it's literally just changing the printout\n> to show the entries marked \"ignored\" with some extra marking.\n\nThis will also fall pretty naturally out of the --merge-order patch\nthat I am working on with an appropiate tweak. But I'll shut up about\nthat until I have code to share...\n\njon.\n"},{"id":"4374","messageId":"pan.2005.06.01.16.38.35.273889@smurf.noris.de","threadId":"773","inReplyTo":"Pine.LNX.4.58.0505310813540.1876@ppc970.osdl.org","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-06-01T16:38:45Z","receivedAt":"2005-06-01T16:38:45Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Linus Torvalds wrote:\n\n> So I guess you'll have to wait for the end and do the toposort after all.\n\nWe could add a cache file, listing commit nodes which predate one of\ntheir parents. Hit one of those and you know you need to immediately\nexamine their parents instead of waiting for them to come up in date order.\n\nThere shouldn't be too many of those in any tree.\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nTruth is a statue, and you are all just a bunch of pigeons.\n\n\n"},{"id":"4547","messageId":"7vekbigo8q.fsf@assigned-by-dhcp.cox.net","threadId":"773","inReplyTo":"Pine.LNX.4.58.0505310813540.1876@ppc970.osdl.org","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-04T15:01:25Z","receivedAt":"2005-06-04T15:01:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus, what do you think rev-list should do given HEADs from two\nforks, like this?\n\n JC git-rev-list JC LT ????\n |\n | LT\n | |\n \\ /\n |\n |\n |\n\nThe above is often the shape of my working repository. I pull\nfrom you, commit a handful on top of your then-HEAD, and when I\nam about ready to submit, I pull from you again to find your\nHEAD advanced somewhat.\n\nFor patch-form submission, I need a list of my commits since I\nforked from you. Also I tend to rebase to your head often,\ninstead of merging inside my working repository (which makes\nlater e-mail patch-form submission more work for me), so even\nwhen I am not immediately submitting the changes I have in my\nfork, I need that list to forward port my changes.\n\nJIT currently uses this to get this list (as a workaround):\n\n git-rev-list JC $(merge-base JC LT)\n\nI am wondering if this \"since they forked\" is usually what the\nuser wants. If that is the case then it would be great if I did\nnot have to do the \"merge-base\" part outside.\n\nCurrent \"proper lazy reachability\" version, btw, does something\nvery unexpected for my use pattern. If you have more than one\ncommits between the fork point and LT HEAD in the above picture,\neverything from the beginning of time to JC is given, or\nsomething silly like that.\n\n\n"},{"id":"4548","messageId":"20050604150935.GB5120@cip.informatik.uni-erlangen.de","threadId":"773","inReplyTo":"7vekbigo8q.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-06-04T15:09:35Z","receivedAt":"2005-06-04T15:09:35Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello Junio,\nI pull the REMOTE_HEAD including objects but don't merge. After that I\nrun:\n\nsystem(\"git-rev-tree HEAD REMOTE_HEAD | sed -e 's/^[0-9]* //' | git-diff-tree --stdin -v \");\n\nfor bitkeeper I used the merge base approach (but at that time I only\nknew that this gives me any deltas in the current tree not in the remote\ntree, but didn't know how it worked).\n\nbkparentdiff is aliased to `bk rset -hr`bk repogca`,+ | grep -v ^BitKeeper | bk gnupatch -du -e -h -T'\n\n\tThomas\n"},{"id":"4549","messageId":"Pine.LNX.4.58.0506040837190.1876@ppc970.osdl.org","threadId":"773","inReplyTo":"7vekbigo8q.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-04T15:42:46Z","receivedAt":"2005-06-04T15:42:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 4 Jun 2005, Junio C Hamano wrote:\n>\n> Linus, what do you think rev-list should do given HEADs from two\n> forks, like this?\n> \n> JC git-rev-list JC LT ????\n> |\n> | LT\n> | |\n> \\ /\n> |\n> |\n> |\n\nAhh. Ok, I'll fix it. Indeed, I think it should give everything up to the \nmerge base.\n\n> Current \"proper lazy reachability\" version, btw, does something\n> very unexpected for my use pattern. If you have more than one\n> commits between the fork point and LT HEAD in the above picture,\n> everything from the beginning of time to JC is given, or\n> something silly like that.\n\nYes. The whole thing is written to literally expect to see the \"stop here\" \nthing, and that's when it starts poisoning the well.\n\nDoes this fix it for you (untested, of course)?\n\n\t\tLinus\n---\ndiff --git a/rev-list.c b/rev-list.c\n--- a/rev-list.c\n+++ b/rev-list.c\n@@ -160,6 +160,8 @@ int main(int argc, char **argv)\n \t\tend = lookup_commit_reference(sha1[1]);\n \t\tif (!end || parse_commit(end) < 0)\n \t\t\tdie(\"bad ending commit object\");\n+\t\tend->object.flags |= UNINTERESTING;\n+\t\tcommit_list_insert(end, &list);\n \t}\n \n \tcommit_list_insert(commit, &list);\n"},{"id":"4550","messageId":"Pine.LNX.4.58.0506040847170.1876@ppc970.osdl.org","threadId":"773","inReplyTo":"Pine.LNX.4.58.0506040837190.1876@ppc970.osdl.org","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-04T15:51:13Z","receivedAt":"2005-06-04T15:51:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 4 Jun 2005, Linus Torvalds wrote:\n> \n> Does this fix it for you (untested, of course)?\n\nBtw, as shown by this patch, the lazy git-rev-list algorithm is actually\n_supposed_ to be able to handle a lot more complicated cases than what the \ncommand line interface allows.\n\nIn other words, maybe I should have used the same syntax as for \ngit-rev-tree, because it _can_ handle things like \"show me all revisions \nthat are reachable from a or b, but are _not_ reachable from c or d or e.\n\nIs that useful? I dunno. It might be useful for somebody like Jeff, who\nhas lots of different heads, and he could say \"ok, show me what is in all\nmy network driver heads, but isn't in linus' tree\".\n\nWould people prefer to have \"git-rev-list\" take arguments like\n\n\tgit-rev-list a b ^c ^d\n\nthe way git-rev-tree does?\n\n\t\tLinus\n"},{"id":"4552","messageId":"7v7jh9hqc5.fsf@assigned-by-dhcp.cox.net","threadId":"773","inReplyTo":"Pine.LNX.4.58.0506040847170.1876@ppc970.osdl.org","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-04T19:30:50Z","receivedAt":"2005-06-04T19:30:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> On Sat, 4 Jun 2005, Linus Torvalds wrote:\n\n>> Does this fix it for you (untested, of course)?\n\nWill check later.\n\nLT> Would people prefer to have \"git-rev-list\" take arguments like\nLT> \tgit-rev-list a b ^c ^d\nLT> the way git-rev-tree does?\n\nI do not expect myself to maintain many heads like Jeff, I\ncannot comment on how well that \"many heads\" feature would work\nin practice, but I would vote \"a ^b\" syntax to match\ngit-rev-tree.\n\n\n\n\n\n"},{"id":"4553","messageId":"7v1x7hhpuq.fsf@assigned-by-dhcp.cox.net","threadId":"773","inReplyTo":"Pine.LNX.4.58.0506040837190.1876@ppc970.osdl.org","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-04T19:41:17Z","receivedAt":"2005-06-04T19:41:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> Yes. The whole thing is written to literally expect to see the \"stop here\" \nLT> thing, and that's when it starts poisoning the well.\n\nLT> Does this fix it for you (untested, of course)?\n\nYes, it does.\n\n\n"},{"id":"4554","messageId":"20050604194626.GA7084@pasky.ji.cz","threadId":"773","inReplyTo":"Pine.LNX.4.58.0506040847170.1876@ppc970.osdl.org","subject":"Re: git-rev-list: proper lazy reachability","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-06-04T19:46:26Z","receivedAt":"2005-06-04T19:46:26Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Jun 04, 2005 at 05:51:13PM CEST, I got a letter\nwhere Linus Torvalds told me that...\n> Would people prefer to have \"git-rev-list\" take arguments like\n> \n> \tgit-rev-list a b ^c ^d\n> \n> the way git-rev-tree does?\n\nYes, please. I think that usage is more consistent and more flexible.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"}]}