{"thread":{"id":"364","subject":"kernel.org now has gitweb installed","startedAt":"2005-04-28T01:38:01Z","lastAt":"2005-04-29T02:46:49Z","messageCount":23,"participants":["H. Peter Anvin","Daniel Jacobowitz","David Woodhouse","Petr Baudis","Linus Torvalds","Junio C Hamano","Gerhard Schrenk","Jan Harkes"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"1968","messageId":"42703E79.8050808@zytor.com","threadId":"364","inReplyTo":null,"subject":"kernel.org now has gitweb installed","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-04-28T01:38:01Z","receivedAt":"2005-04-28T01:38:01Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"http://www.kernel.org/git/\n\n\t-hpa\n"},{"id":"1988","messageId":"20050428041750.GA8239@nevyn.them.org","threadId":"364","inReplyTo":"42703E79.8050808@zytor.com","subject":"Re: kernel.org now has gitweb installed","fromName":"Daniel Jacobowitz","fromEmail":"dan@debian.org","sentAt":"2005-04-28T04:17:50Z","receivedAt":"2005-04-28T04:17:50Z","isPatch":false,"sender":{"key":"dan@debian.org","avatar":null},"body":"On Wed, Apr 27, 2005 at 06:38:01PM -0700, H. Peter Anvin wrote:\n> http://www.kernel.org/git/\n\nThanks! Now all I crave is a version which can browse the file tree\nand file history; but I think we're almost ready for that...\n\n-- \nDaniel Jacobowitz\nCodeSourcery, LLC\n"},{"id":"2013","messageId":"1114673723.12012.324.camel@baythorne.infradead.org","threadId":"364","inReplyTo":"42703E79.8050808@zytor.com","subject":"Re: kernel.org now has gitweb installed","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-28T07:35:23Z","receivedAt":"2005-04-28T07:35:23Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Wed, 2005-04-27 at 18:38 -0700, H. Peter Anvin wrote:\n> http://www.kernel.org/git/\n\nLooks like the ordering is wrong. A chronological sort means that\ncommits which were made three weeks ago, but which Linus only pulled\nyesterday, do not show up at the top of the tree.\n\n-- \ndwmw2\n\n\n"},{"id":"2015","messageId":"20050428081005.GG8612@pasky.ji.cz","threadId":"364","inReplyTo":"1114673723.12012.324.camel@baythorne.infradead.org","subject":"Re: kernel.org now has gitweb installed","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-04-28T08:10:05Z","receivedAt":"2005-04-28T08:10:05Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Apr 28, 2005 at 09:35:23AM CEST, I got a letter\nwhere David Woodhouse told me that...\n> On Wed, 2005-04-27 at 18:38 -0700, H. Peter Anvin wrote:\n> > http://www.kernel.org/git/\n> \n> Looks like the ordering is wrong. A chronological sort means that\n> commits which were made three weeks ago, but which Linus only pulled\n> yesterday, do not show up at the top of the tree.\n\n Linus ASM (Anonymous Subsystem Maintainer)\n\n |------------------------.\n A| |B\n | |\n | \\-------------\\\n | : |\n \\------------------------\\ |E\n C| |D |\n | /-------------/\n | |F\n /------------------------/\n\nHow would you show that? F E D C B A? F D C A E B?\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"},{"id":"2017","messageId":"1114676955.12012.346.camel@baythorne.infradead.org","threadId":"364","inReplyTo":"20050428081005.GG8612@pasky.ji.cz","subject":"Re: kernel.org now has gitweb installed","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-28T08:29:15Z","receivedAt":"2005-04-28T08:29:15Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2005-04-28 at 10:10 +0200, Petr Baudis wrote:\n> Linus ASM (Anonymous Subsystem Maintainer)\n> \n> |------------------------.\n> A| |B\n> | |\n> | \\-------------\\\n> | : |\n> \\------------------------\\ |E\n> C| |D |\n> | /-------------/\n> | |F\n> /------------------------/\n> \n> How would you show that? F E D C B A? F D C A E B?\n\nLet us assume that C and A were already in Linus' tree (and on our web\npage) yesterday. Thus, they should be last. The newly-pulled stuff\nshould be first -- FEDBCA.\n\nI'd say \"depth-first, remote parent first\" but that would actually show\nshow 'A' (as a parent of D) long before it shows C. Walking of remote\nparents should stop as soon as we hit a commit which was accessible\nthrough a more local parent, rather than as soon as we hit a commit\nwhich we've already printed. Maybe it should be something like depth-\nfirst, local parent first, but _reversed_?\n\nThe latter is what the mailing list feeder does, but that has the\nadvantage of being about to use 'rev-tree $today ^$yesterday' so we\n_know_ we're excluding the ones people have already seen. Hence I\nhaven't really paid that much attention to getting the order strictly\ncorrect.\n\n(Yes, I know that strictly speaking, git has no concept of 'remote' or\n'local' parents. But the ordering of the two parents in a Cogito merge\nor pull hasn't changed, has it?)\n\n-- \ndwmw2\n\n\n"},{"id":"2021","messageId":"1114680199.12012.363.camel@baythorne.infradead.org","threadId":"364","inReplyTo":"1114676955.12012.346.camel@baythorne.infradead.org","subject":"Re: kernel.org now has gitweb installed","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-28T09:23:19Z","receivedAt":"2005-04-28T09:23:19Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2005-04-28 at 09:29 +0100, David Woodhouse wrote:\n> Let us assume that C and A were already in Linus' tree (and on our web\n> page) yesterday. Thus, they should be last. The newly-pulled stuff\n> should be first -- FEDBCA.\n> \n> I'd say \"depth-first, remote parent first\" but that would actually show\n> show 'A' (as a parent of D) long before it shows C. Walking of remote\n> parents should stop as soon as we hit a commit which was accessible\n> through a more local parent, rather than as soon as we hit a commit\n> which we've already printed.\n\nWalk the tree once. For each commit, count the number of _children_.\nThat's not hard -- each new commit you find below HEAD has one child to\nstart with, then you increment that figure by one each time you find\nanother path to the same commit.\n\nWhen printing, you walk the tree depth-first, remote-parent-first. If\nyou hit a commit with multiple children, decrement its count by one. If\nthe count is still non-zero, ignore that commit (and its parents) and\ncontinue. If the count _is_ zero, then this is the \"most local\" path to\nthe commit in question, so print it and continue to process its\nparents...\n\n(Actually I'd probably do it by adding real pointers to the children\ninstead of using a counter. Operations like convert-cache would be far\nbetter off working that way round, and 'cg comments' is going to need to\ndo something very similar to convert-cache.)\n\n-- \ndwmw2\n\n\n"},{"id":"2064","messageId":"Pine.LNX.4.58.0504281149330.18901@ppc970.osdl.org","threadId":"364","inReplyTo":"1114680199.12012.363.camel@baythorne.infradead.org","subject":"Re: kernel.org now has gitweb installed","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-28T18:55:16Z","receivedAt":"2005-04-28T18:55:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Apr 2005, David Woodhouse wrote:\n> \n> Walk the tree once. For each commit, count the number of _children_.\n> That's not hard -- each new commit you find below HEAD has one child to\n> start with, then you increment that figure by one each time you find\n> another path to the same commit.\n> \n> When printing, you walk the tree depth-first, remote-parent-first.\n\nNo, that really sucks. \n\nRealize that \"remote\" and \"local\" parents don't really exist. They have no \nmeaning. I've considered sorting the parents by the sha1 name, but I've \nleft that for now.\n\nAnyway, the reason remote and local don't matter is that if somebody else\nmerges with me, and I just pull the result without having any changes in \nmy tree, we just \"fast-forward\" to that other side, because otherwise you \ncan never \"converge\" on anything (people merging each others trees would \nalways create a new commit, for no good reason).\n\nWhat does that mean? It means that my local tree now became the _remote_ \nparent, even though it was always local to my tree.\n\nSo if you look at remote vs local, you're _guaranteed_ to mess up. It has \nno meaning.\n\nSo what you can do is:\n - if there is one parent, just always walk straight down\n - if it's a merge, add the parents _in_date_order_ to the list of things \n to do, and then pop the most recent one.\n\nReally. You say that dates don't matter, but they _do_ actually matter a\nlot more than \"remote/local\" does. At least they have meaning.\n\n\t\tLinus\n"},{"id":"2081","messageId":"1114723214.2734.9.camel@localhost.localdomain","threadId":"364","inReplyTo":"Pine.LNX.4.58.0504281149330.18901@ppc970.osdl.org","subject":"Re: kernel.org now has gitweb installed","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-28T21:20:14Z","receivedAt":"2005-04-28T21:20:14Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2005-04-28 at 11:55 -0700, Linus Torvalds wrote:\n> Anyway, the reason remote and local don't matter is that if somebody else\n> merges with me, and I just pull the result without having any changes in \n> my tree, we just \"fast-forward\" to that other side, because otherwise you \n> can never \"converge\" on anything (people merging each others trees would \n> always create a new commit, for no good reason).\n> \n> What does that mean? It means that my local tree now became the _remote_ \n> parent, even though it was always local to my tree.\n\nHmm, that's true; albeit unfortunate. \n\nStill, using the date isn't any better. It'll give results which are\nabout as random as just sorting by the sha1 of each parent.\n\nYes, the ordering of the parents in a merge is probably meaningless in\nthe general case, but so is the date.\n\nThe best we could probably do, from a theoretical standpoint, is to look\nat the paths via each parent to a common ancestor, and look at how many\nof the commits on each path were done by the same committer. Even that\nisn't ideal, and it's probably fairly expensive -- but it's pointless to\npretend we can infer anything from _either_ the dates or the ordering of\nthe parents in a merge.\n\n-- \ndwmw2\n\n"},{"id":"2080","messageId":"7v1x8u7g26.fsf@assigned-by-dhcp.cox.net","threadId":"364","inReplyTo":"Pine.LNX.4.58.0504281149330.18901@ppc970.osdl.org","subject":"Re: kernel.org now has gitweb installed","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-04-28T21:21:53Z","receivedAt":"2005-04-28T21:21:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> So what you can do is:\nLT> - if there is one parent, just always walk straight down\nLT> - if it's a merge, add the parents _in_date_order_ to the list of things \nLT> to do, and then pop the most recent one.\nLT> Really. You say that dates don't matter, but they _do_ actually matter a\nLT> lot more than \"remote/local\" does. At least they have meaning.\n\nOn a related topic, I have two questions on commit objects.\n\n1. Currently, commit-tree does not seem to verify that all its\n parent SHA1's actually name valid commit objects. Is this\n intentional?\n\nI cannot see a good practical reason to commit a new version\nthat claim to be descendant of some SHA1 you know exists in\nsomebody else's tree, without actually having that object also\nin your SHA1_FILE_DIRECTORY. Otherwise how did you merge with\nit in the first place? For that reason, I expect the answer to\nthis question to be \"no it was just being lazy. Go ahead if you\nreally care.\"\n\n2. Assuming that we do want to enforce that parent fields of a\n commit object name valid commit objects, is it OK to also\n require that the commit timestamp of a child object is not in\n the future relative to any and all of its parent commit\n objects (I'm talking about the timestamp of committer field\n not author field, although your e-mail patch acceptance\n procedure seems to be giving it the same timestamp right\n now)?\n\nI have been wondering if imposing these two requirement has some\nnegative effects, but I do not offhand see any. And these\nrequirements may make implementation of git log viewer simpler\nwhen the user specifies \"I want to view commit between these\nones---give me a linearlized list of commits.\" When following\nthe ancestor chain from the current top, we can immediately stop\nupon seeing a commit made before the timestamp of the named\nbottom one.\n\n"},{"id":"2082","messageId":"1114723402.2734.11.camel@localhost.localdomain","threadId":"364","inReplyTo":"7v1x8u7g26.fsf@assigned-by-dhcp.cox.net","subject":"Re: kernel.org now has gitweb installed","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-28T21:23:21Z","receivedAt":"2005-04-28T21:23:21Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2005-04-28 at 14:21 -0700, Junio C Hamano wrote:\n> 2. Assuming that we do want to enforce that parent fields of a\n> commit object name valid commit objects, is it OK to also\n> require that the commit timestamp of a child object is not in\n> the future relative to any and all of its parent commit\n> objects\n\nNo. Time is utterly meaningless -- it's perfectly normal for clocks to\nbe out of sync. We really don't want to fall into the trap of assigning\nany meaning to the timestamp.\n\n-- \ndwmw2\n\n"},{"id":"2088","messageId":"1114724307.2734.17.camel@localhost.localdomain","threadId":"364","inReplyTo":"7v1x8u7g26.fsf@assigned-by-dhcp.cox.net","subject":"Re: kernel.org now has gitweb installed","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-28T21:38:26Z","receivedAt":"2005-04-28T21:38:26Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2005-04-28 at 14:21 -0700, Junio C Hamano wrote:\n> \"I want to view commit between these ones---give me a linearlized list\n> of commits.\" When following the ancestor chain from the current top,\n> we can immediately stop upon seeing a commit made before the timestamp\n> of the named bottom one.\n\nThis absolutely must not be timestamp based. If I ask for a list of\ncommits before 2.6.12-rc3 and 2.6.12-rc4 I _really_ want to see those\ncommits which happened before 2.6.12-rc3 but in a remote tree which was\nonly later pulled. That's what 'rev-tree AAAAAA ^BBBBBB' already gives\nyou.\n\n-- \ndwmw2\n\n"},{"id":"2087","messageId":"Pine.LNX.4.58.0504281432490.18901@ppc970.osdl.org","threadId":"364","inReplyTo":"1114723214.2734.9.camel@localhost.localdomain","subject":"Re: kernel.org now has gitweb installed","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-28T21:40:45Z","receivedAt":"2005-04-28T21:40:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Apr 2005, David Woodhouse wrote:\n> \n> Still, using the date isn't any better. It'll give results which are\n> about as random as just sorting by the sha1 of each parent.\n\nWell, it does use real information, and it is repeatable. And I don't see \nwhy you say that the date is meaningless, when it clearly isn't. The date \nabsolutely does have meaning. \n\nNot having a global clock doesn't mean that clocks go away. It just means \nthat they don't generate a total sort. They still generate a _partial_ \nsort, though, and it's a very valid partial sort.\n\nThe fact is, this is how the world works in real life too. Relativity \ndoesn't make time \"pointless\". You still have \"before\" and \"after\" for \nalmost all relevant events. The fact that not _all_ events can be sorted \nby \"before\" and \"after\", and different observers can disagree about some \nof the ordering does not mean that causality has gone away and that time \nis meaningless.\n\nThe same is true in a distributed system. Time still exists, and is still \nmeaningful even outside the direct \"causality\" links implied by the \nparents. People probably discussed things, and there are methods of \ncommunication other than just direct parent links, and while you're not \n_guaranteed_ that \"before\" and \"after\" always makes sense, they definitely \nstill exist 99% of the time.\n\n> The best we could probably do, from a theoretical standpoint, is to look\n> at the paths via each parent to a common ancestor, and look at how many\n> of the commits on each path were done by the same committer.\n\nThat's quite expensive. \n\n> Even that isn't ideal, and it's probably fairly expensive -- but it's\n> pointless to pretend we can infer anything from _either_ the dates or\n> the ordering of the parents in a merge.\n\nWrong. The date _does_ have meaning. It shows which of the parents was \nmore recent, which indirectly is a hint about which side had more activity \ngoing on. \n\nIn other words, it _is_ meanginful. Maybe it's a _statistical_ meaning \n(\"that side is probably the active one, because it has the last commit\"), \nbut it's a meaning.\n\n\t\tLinus\n"},{"id":"2089","messageId":"Pine.LNX.4.58.0504281441070.18901@ppc970.osdl.org","threadId":"364","inReplyTo":"7v1x8u7g26.fsf@assigned-by-dhcp.cox.net","subject":"Re: kernel.org now has gitweb installed","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-28T21:44:16Z","receivedAt":"2005-04-28T21:44:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Apr 2005, Junio C Hamano wrote:\n> \n> 1. Currently, commit-tree does not seem to verify that all its\n> parent SHA1's actually name valid commit objects. Is this\n> intentional?\n\nNo. Me lazy. I think we should check as many _cheap_ things as possible,\nand checking whether a parent at least superficially looks like a real\ncommit object is certainly cheap.\n\n> 2. Assuming that we do want to enforce that parent fields of a\n> commit object name valid commit objects, is it OK to also\n> require that the commit timestamp of a child object is not in\n> the future relative to any and all of its parent commit\n> objects (I'm talking about the timestamp of committer field\n> not author field, although your e-mail patch acceptance\n> procedure seems to be giving it the same timestamp right\n> now)?\n\nNo, this is not ok. Clock skew is real, and somebody may have a \nmisconfigured machine. Being careful about integrity is good, but trying \nto enforce time flow in a distributed environment is just being anal.\n\nMaybe a warning.\n\n\t\tLinus\n"},{"id":"2090","messageId":"7voeby60fp.fsf@assigned-by-dhcp.cox.net","threadId":"364","inReplyTo":"1114723402.2734.11.camel@localhost.localdomain","subject":"Re: kernel.org now has gitweb installed","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-04-28T21:44:42Z","receivedAt":"2005-04-28T21:44:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"DW\" == David Woodhouse writes:\n\nDW> On Thu, 2005-04-28 at 14:21 -0700, Junio C Hamano wrote:\n>> 2. Assuming that we do want to enforce that parent fields of a\n>> commit object name valid commit objects, is it OK to also\n>> require that the commit timestamp of a child object is not in\n>> the future relative to any and all of its parent commit\n>> objects\n\nDW> No. Time is utterly meaningless -- it's perfectly normal for clocks to\nDW> be out of sync. We really don't want to fall into the trap of assigning\nDW> any meaning to the timestamp.\n\nIf that is really the case, shouldn't we do one of the\nfollowing:\n\n (1) Timestamp is meaningless. Stop recording it in the commit\n objects.\n\n (2) Keep recording meaningless timestamp in the commit objects,\n because otherwise it would break backward compatibility.\n However, stop looking at timestamp in commit.c; especially\n pop_most-recent_commit() is meaningless hance what rev-list\n does.\n\n (3) Require the proper ordering in the timestamp as I\n suggested. Users should take note and make corrective\n action if their clocks are _way_ out of sync.\n\nI do not think we want to do either (1) or (2).\n\n"},{"id":"2094","messageId":"1114724866.2734.27.camel@localhost.localdomain","threadId":"364","inReplyTo":"Pine.LNX.4.58.0504281432490.18901@ppc970.osdl.org","subject":"Re: kernel.org now has gitweb installed","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-28T21:47:46Z","receivedAt":"2005-04-28T21:47:46Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2005-04-28 at 14:40 -0700, Linus Torvalds wrote:\n> Wrong. The date _does_ have meaning. It shows which of the parents was \n> more recent, which indirectly is a hint about which side had more activity \n> going on. \n> \n> In other words, it _is_ meanginful. Maybe it's a _statistical_ meaning \n> (\"that side is probably the active one, because it has the last commit\"), \n> but it's a meaning.\n\nIt's not entirely clear what 'active' is supposed to be useful for in\nthis instance. You could just as well count the commits between the\nmerge and the common ancestor, if you want to see which side was most\n_active_ -- but that isn't helpful for deciding the order in which\n'cg-log' should show commits.\n\nWhat you really want there is 'local' vs. 'remote', because people want\nto see the order in which changesets arrived in the _local_ repository\n-- if the last thing you did was pull from me, people want all my\nchangesets to be at the top; regardless of who last committed to their\ntree before the merge -- i.e. regardless of whether I did a last-minute\ncommit before you pulled, or whether you'd done another commit to your\ntree immediately before pulling.\n\nAs you rightly point out, the local/remote information isn't really\navailable in an easy form -- certainly not from the ordering of the\nparents in a merge commit. But let's not fool ourselves that we can\npiece it together from the date either.\n\nOK, the date _is_ meaningful in a way, but only in the same way that the\nauthor's name and IRC address information is meaningful. Of course we\ndidn't include it for _nothing_, but it's outside the scope of git\nitself; it isn't part of the useful information which git should care\nabout.\n\n-- \ndwmw2\n\n"},{"id":"2093","messageId":"7vk6mm608e.fsf@assigned-by-dhcp.cox.net","threadId":"364","inReplyTo":"1114724307.2734.17.camel@localhost.localdomain","subject":"Re: kernel.org now has gitweb installed","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-04-28T21:49:05Z","receivedAt":"2005-04-28T21:49:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"DW\" == David Woodhouse writes:\n\nDW> On Thu, 2005-04-28 at 14:21 -0700, Junio C Hamano wrote:\n>> \"I want to view commit between these ones---give me a linearlized list\n>> of commits.\" When following the ancestor chain from the current top,\n>> we can immediately stop upon seeing a commit made before the timestamp\n>> of the named bottom one.\n\nDW> This absolutely must not be timestamp based. If I ask for a list of\nDW> commits before 2.6.12-rc3 and 2.6.12-rc4 I _really_ want to see those\nDW> commits which happened before 2.6.12-rc3 but in a remote tree which was\nDW> only later pulled. That's what 'rev-tree AAAAAA ^BBBBBB' already gives\nDW> you.\n\nHow true. I stand corrected.\n\n"},{"id":"2095","messageId":"42715A8F.8010803@zytor.com","threadId":"364","inReplyTo":"1114723214.2734.9.camel@localhost.localdomain","subject":"Re: kernel.org now has gitweb installed","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-04-28T21:50:07Z","receivedAt":"2005-04-28T21:50:07Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"David Woodhouse wrote:\n> \n> Hmm, that's true; albeit unfortunate. \n> \n> Still, using the date isn't any better. It'll give results which are\n> about as random as just sorting by the sha1 of each parent.\n> \n> Yes, the ordering of the parents in a merge is probably meaningless in\n> the general case, but so is the date.\n> \n> The best we could probably do, from a theoretical standpoint, is to look\n> at the paths via each parent to a common ancestor, and look at how many\n> of the commits on each path were done by the same committer. Even that\n> isn't ideal, and it's probably fairly expensive -- but it's pointless to\n> pretend we can infer anything from _either_ the dates or the ordering of\n> the parents in a merge.\n> \n\nPerhaps the right thing to do is to draw a graph instead?\n\n\t-hpa\n"},{"id":"2096","messageId":"42715B30.6010705@zytor.com","threadId":"364","inReplyTo":"1114723214.2734.9.camel@localhost.localdomain","subject":"Re: kernel.org now has gitweb installed","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-04-28T21:52:48Z","receivedAt":"2005-04-28T21:52:48Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"David Woodhouse wrote:\n> \n> Hmm, that's true; albeit unfortunate. \n> \n> Still, using the date isn't any better. It'll give results which are\n> about as random as just sorting by the sha1 of each parent.\n> \n> Yes, the ordering of the parents in a merge is probably meaningless in\n> the general case, but so is the date.\n> \n> The best we could probably do, from a theoretical standpoint, is to look\n> at the paths via each parent to a common ancestor, and look at how many\n> of the commits on each path were done by the same committer. Even that\n> isn't ideal, and it's probably fairly expensive -- but it's pointless to\n> pretend we can infer anything from _either_ the dates or the ordering of\n> the parents in a merge.\n> \n\nI thought about this for a few seconds (I really should do that more \noften...) and realized what it is you want: you want a primary search \ncriterion which is \"when did event X become visible to me\", where \"me\" \nin this case is the web tool. That is not repository information, but \nit is perfectly possible for the webtool to be aware of what it has \npreviously seen and when.\n\nAnd yes, this ordering is clearly different for each observer.\n\n\t-hpa\n"},{"id":"2097","messageId":"Pine.LNX.4.58.0504281451320.18901@ppc970.osdl.org","threadId":"364","inReplyTo":"7voeby60fp.fsf@assigned-by-dhcp.cox.net","subject":"Re: kernel.org now has gitweb installed","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-28T22:04:56Z","receivedAt":"2005-04-28T22:04:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Apr 2005, Junio C Hamano wrote:\n> \n> If that is really the case, shouldn't we do one of the\n> following:\n\nNo. It's not the case that time-stamps are meaningless. \n\nThe thing about distributed stuff is that time gets \"fuzzy\". It doesn't go \naway. It's still very valid to say \"this was done yesterday\".\n\nBut what gets fuzzy is \"before\" and \"after\". For two reasons:\n\n - time isn't synchronized, and clocks can be off. Usually by just a \n little bit, but sometimes you'll find just plain badly maintained \n machines, and time can be a year or two off.\n\n Ergo: time is a _hint_. It's usually a pretty good hint, but it's a \n hint.\n\n - the \"parent\" relationship is the only \"hard\" before/after thing that \n git knows about, but it ignores a lot of real-world interaction, so\n thinking that it is the _only_ before/after measure is ignoring all the\n other communication in a system.\n\n So parenthood guarantees that something happened \"before\", but _not_ \n being directly related doesn't mean that they were totally independent. \n There's no fixed \"speed of light\" that defines some absolute \"cone of \n reachability\".\n\nSo time is relevant, but it's more of a hint than anything absolute. \nAnything that -depends- on time is a bug waiting to happen, but something \nthat uses time to visualize things makes sense.\n\nThe big advantage with time is that it's cheap. If you want to do a full \nreachability analysis, you have to look at the whole revision tree. That's \nquite possible RIGHT NOW, but it simply ill not be practical in a year, \nwhen we have 15,000 commits.\n\nSo \"time\" ends up being an approximation for \"doing it right\".\n\nAs an example: it's quite expensive to ask \"was this commit part of \n2.6.12-rc3?\" because that involves knowing the whole set of commits \ninvolved in 2.6.12-rc3. Which in turn involves walking the whole revision \ntree starting at 2.6.12-rc3 downwards. \n\nThat's exactly what \"rev-tree\" does, though. \"rev-tree\" will do the whole\nreachability thing, and as a result you can see whether something was in\n2.6.12-rc3 or not. But just for fun - time how long it takes for\n\"rev-tree\" to output its first entry, and how long it takes for \"rev-list\"\nto print its first line. \n\nHint: do it with a cold-cache \"sparse\" tree. \"rev-list\" will start\noutputting data immediately, and work it out as it goes along. \"rev-tree\" \nwill think for some time, and then blast the data out.\n\nIn other words: rev-list is what you want for something like \"git log\", \nbecause you care about _latency_ of the result.\n\nAnd that's why it uses time. It's an approximation, but it is an \napproximation that has meaning in real life.\n\n\t\tLinus\n"},{"id":"2100","messageId":"Pine.LNX.4.58.0504281506500.18901@ppc970.osdl.org","threadId":"364","inReplyTo":"42715B30.6010705@zytor.com","subject":"Re: kernel.org now has gitweb installed","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-04-28T22:12:23Z","receivedAt":"2005-04-28T22:12:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Apr 2005, H. Peter Anvin wrote:\n>\n> I thought about this for a few seconds (I really should do that more \n> often...) and realized what it is you want: you want a primary search \n> criterion which is \"when did event X become visible to me\", where \"me\" \n> in this case is the web tool. That is not repository information, but \n> it is perfectly possible for the webtool to be aware of what it has \n> previously seen and when.\n\nThis is exactly what rev-tree does, and how things like the commit emails \nhappen.\n\nThe problem is that since it's observer-dependent, it's not generally very \nuseful for something like a web interface. You really don't want to keep \ntrack of what everybody has seen ;)\n\nWhat you _can_ try to keep track of is what some \"special observer\" has\nseen. That's really quite complicated too, but if you do a web interface,\nthe \"special observer\" is yourself. Then at every time you mirror the\nthing, you need to remember what your \"last view\" was, and you base your\n\"new view\" on the fact that you know what you saw last time, so you know\nwhich things are new to _you_.\n\nBut it really means that each web interface ends up showing quite\n_different_ information, and the particular information you show ends up\nbeing dependent on when you started looking at the tree (and how often you\nre-generate new views).\n\nThis really is why \"time\" is interesting. Because it's simple, and \nobservers can agree about it (not because the time was the same, but \nbecause each observer just agrees that time is \"whatever was reported as \nthe local time at the point the action happened\").\n\n\t\tLinus\n"},{"id":"2101","messageId":"1114726373.2734.47.camel@localhost.localdomain","threadId":"364","inReplyTo":"42715B30.6010705@zytor.com","subject":"Re: kernel.org now has gitweb installed","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2005-04-28T22:12:52Z","receivedAt":"2005-04-28T22:12:52Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2005-04-28 at 14:52 -0700, H. Peter Anvin wrote:\n> I thought about this for a few seconds (I really should do that more \n> often...) and realized what it is you want: you want a primary search \n> criterion which is \"when did event X become visible to me\", where \"me\" \n> in this case is the web tool. That is not repository information, but \n> it is perfectly possible for the webtool to be aware of what it has \n> previously seen and when.\n> \n> And yes, this ordering is clearly different for each observer.\n\nThe mailing list does it with tags -- it remembers the 'last seen\ncommit' and then effectively does 'rev-tree HEAD ^LASTSEEN', except that\nI make a primitive attempt to get the ordering a little better than what\nI get from rev-tree. But since the mailing list runs are hourly, I\nreally can get away with a _primitive_ attempt. That's why I hadn't\nnoticed the local/remote ordering problem that Linus pointed out.\n\nIt's not clear how you'd attempt to track local history for the general\ncase though -- the whole concept of a 'local' branch being special is\nanathema to git. You'd have to hack it into some auxiliary storage, as I\ndo with tags -- but to get a fullly correct ordering it'd have to track\nat least every locally-performed merge, and you really don't want to be\ndoing that kind of thing.\n\nYou might perhaps attempt to find a path through the graph which takes\nin as many commits as possible where committer == `logname`@`hostname`\n-- but as Linus and I already said, that's expensive.\n\nI'm not entirely sure what the answer is; but it isn't parent ordering\nand it isn't dates.\n\nUsing dates might be a nice quick approximation, but that really isn't\ngood enough. \n\nI wonder if we could try to enforce some meaning for dates though....\nCurrently, 'rev-tree AAAA ^BBBB' has to build the _entire_ tree for BBBB\nback to the beginning, so it knows where to stop when following AAAA. \n\nHowever, if we _do_ take Junio's suggesting of enforcing monotonicity,\nthen we'll always know that the parents of a given commit will have a\ntimestamp which is older than its own timestamp. \n\nSo given the task \"list commits between 2.6.12-rc3 and 2.6.12-rc4' we\ncould look at the timestamp of rc3, and immediately follow the rc4\nparents until we start seeing commits which are older than rc3. Then\neach time we hit a commit in the parents of rc4 which is older than rc3\nis, we continue doing a breadth-first search from rc3 until all the\nparents we're looking at are older than the parent of rc4 which we're\ncurrently considering. Etc. \n\nThat means that the common case of \"in A but not in B\" can at least be\nhandled relatively efficiently without having to wait while it tracks\nthe history all the way back to the beginning. I still don't like it\nmuch though...\n\n-- \ndwmw2\n\n"},{"id":"2108","messageId":"20050428225906.GA12592@frodo","threadId":"364","inReplyTo":"1114723402.2734.11.camel@localhost.localdomain","subject":"Re: kernel.org now has gitweb installed","fromName":"Gerhard Schrenk","fromEmail":"gps@mittelerde.physik.uni-konstanz.de","sentAt":"2005-04-28T22:59:07Z","receivedAt":"2005-04-28T22:59:07Z","isPatch":false,"sender":{"key":"gps@mittelerde.physik.uni-konstanz.de","avatar":null},"body":"* David Woodhouse [2005-04-28 23:23]:\n \n> No. Time is utterly meaningless -- \n\nThis is fundamentally wrong. Space-time and causality has a *very*\nimportant meaning. If don't use this information (directly or\nindirectly) in your data modell or history graph you do something very\nstupid. You simply won't optimize for the common case because you won't\nscale with the fundamental physical laws of information exchange and\nsyncronisation, you just kind of break space-time-symmetrie. Ever\ncompared feynman diagrams to merge diagrams?\n\n> it's perfectly normal for clocks to be out of sync.\n\nYes even special relativity just boils down to \"there is no absolut\nsimultaneity\". So what? \n\nI'll predict if you break causality your kernel will suddenly\ndestabilize and explode like a nuclear bomb ;-)\n\nGerhard\n"},{"id":"2115","messageId":"20050429024649.GB11692@delft.aura.cs.cmu.edu","threadId":"364","inReplyTo":"1114726373.2734.47.camel@localhost.localdomain","subject":"Re: kernel.org now has gitweb installed","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2005-04-29T02:46:49Z","receivedAt":"2005-04-29T02:46:49Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Thu, Apr 28, 2005 at 11:12:52PM +0100, David Woodhouse wrote:\n> You might perhaps attempt to find a path through the graph which takes\n> in as many commits as possible where committer == `logname`@`hostname`\n> -- but as Linus and I already said, that's expensive.\n> \n> I'm not entirely sure what the answer is; but it isn't parent ordering\n> and it isn't dates.\n\nPerhaps a lamport clock?\n\nJan\n"}]}