{"thread":{"id":"800","subject":"Re: git-rev-list: proper lazy reachability","startedAt":"2005-06-01T19:02:08Z","lastAt":"2005-06-01T19:02:08Z","messageCount":1,"participants":["Marco Costalba"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"4380","messageId":"20050601190208.76289.qmail@web26310.mail.ukl.yahoo.com","threadId":"800","inReplyTo":null,"subject":"Re: git-rev-list: proper lazy reachability","fromName":"Marco Costalba","fromEmail":"mcostalba@yahoo.it","sentAt":"2005-06-01T19:02:08Z","receivedAt":"2005-06-01T19:02:08Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Tue, 31 May 2005, Linus Torvalds wrote:\n> \n>>You should never see a parent before a child from git-rev-list.\n> \n> \n> Actually, I take that back.\n> \n...\n\n> \n> The thing is, since B has such an \"old\" date, the traversal assumes that\n> it is old and very low down in the tree, and that it's better off parsing\n> other commits first, so it will never look more closely at B and notice\n> that it has a parent that has already been parsed.\n> \n\nIf this is an exception, and I it is, peraphs can be treated in a special way.\n\nAs example, when adding a new parent to the pending list of parents to be processed in time-based\nordering, should be easy to inc a counter if  the last one is always the same, e.g. there is the\nsame very old node around, and check closer to it if the counter reach some allowed maximum.\n\nI know it's a hack, and is not a solution in the general case, but also the last century developer\nclock is very rare, more, it is a warning for a bad commit. \n\nDo not wait for the end of the toposort its a very big advantage for, e.g. GUI git viewers\nlaunched on big trees with long histories.\n\nMarco Costalba\n\n\n\n\n\n\n\n\t\n\n\t\n\t\t\n___________________________________ \nYahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB \nhttp://mail.yahoo.it\n"}]}