{"thread":{"id":"5710","subject":"git and time","startedAt":"2006-09-26T23:23:16Z","lastAt":"2006-10-03T00:01:23Z","messageCount":115,"participants":["Matthew L Foster","Johannes Schindelin","Jakub Narebski","Jeff King","Sean","David Lang","Junio C Hamano","Linus Torvalds","Shawn Pearce","Andreas Ericsson","Edgar Toernig","Andy Whitcroft","Theodore Tso","Nicolas Pitre","Tom Prince","Rogan Dawes","Robin Rosenberg","A Large Angry SCM","Jan Harkes"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"27719","messageId":"20060926232316.98065.qmail@web51009.mail.yahoo.com","threadId":"5710","inReplyTo":null,"subject":"git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-26T23:23:16Z","receivedAt":"2006-09-26T23:23:16Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\nAfter seeing how git currently accepts a remote repository's timestamp it occurred to me that\ngit should probably instead prefer the time a particular changeset was committed to _this_\nrepository. Perhaps I don't know enough about git but it seems to me the important information is\nwhen a particular changeset was committed to this repository, all other remote/sub/parent\nrepositories' timestamps are secondary (or at least should be tracked separately).\n\n-Matt\n\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27720","messageId":"Pine.LNX.4.63.0609270127010.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5710","inReplyTo":"20060926232316.98065.qmail@web51009.mail.yahoo.com","subject":"Re: git and time","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-26T23:27:35Z","receivedAt":"2006-09-26T23:27:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 26 Sep 2006, Matthew L Foster wrote:\n\n> After seeing how git currently accepts a remote repository's timestamp \n> it occurred to me that git should probably instead prefer the time a \n> particular changeset was committed to _this_ repository.\n\nGit accepts it, but does not rely on it. Instead, it relies on \nparent-child relations.\n\nHth,\nDscho\n"},{"id":"27721","messageId":"efcdaq$hld$1@sea.gmane.org","threadId":"5710","inReplyTo":"20060926232316.98065.qmail@web51009.mail.yahoo.com","subject":"Re: git and time","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-26T23:32:50Z","receivedAt":"2006-09-26T23:32:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthew L Foster wrote:\n\n> After seeing how git currently accepts a remote repository's timestamp\n> it occurred to me that git should probably instead prefer the time\n> a particular changeset was committed to _this_ repository. Perhaps\n> I don't know enough about git but it seems to me the important\n> information is when a particular changeset was committed to this\n> repository, all other remote/sub/parent repositories' timestamps\n> are secondary (or at least should be tracked separately). \n\nFirst, the information you want is contained in reflog. Dates the head tip\ngot the specified value.\n\nSecond, git cannot rewrite commits (and commits contain timestamp) when\nfetching commit from remote repository for performance reasons.\n\nThird, git uses timestams as heuristics, but relies on parent information.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27722","messageId":"20060926233321.GA17084@coredump.intra.peff.net","threadId":"5710","inReplyTo":"20060926232316.98065.qmail@web51009.mail.yahoo.com","subject":"Re: git and time","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-09-26T23:33:22Z","receivedAt":"2006-09-26T23:33:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 26, 2006 at 04:23:16PM -0700, Matthew L Foster wrote:\n\n> After seeing how git currently accepts a remote repository's timestamp\n> it occurred to me that git should probably instead prefer the time a\n> particular changeset was committed to _this_ repository. Perhaps I\n\nIf you fetch a commit from a remote repository, it does not get\n\"committed\" to the local repository. It is simply copied. Keep in mind\nthat the act of making a commit means making an immutable SHA1 object.\nIf, when you fetched that commit, you changed some aspect of it (like\nthe timestamp), it would cease to have the same SHA1, and thus the DAG\nof your history would differ from the remote end.\n\nDuring operations where the original commit isn't preserved (e.g.,\napplying patches from an email), git applies the current timestamp as\nthe committer timestamp (but uses the email date as the author\ntimestamp).\n\n> don't know enough about git but it seems to me the important\n> information is when a particular changeset was committed to this\n> repository, all other remote/sub/parent repositories' timestamps are\n> secondary (or at least should be tracked separately).\n\nThat information is not tracked in the commit objects (because they are\nnever \"committed\" in the local repository, only copied); however, Shawn's\nreflog implementation gives some indication of when each ref changed,\nwhich shows when some (but not all) commits made it into the local\nrepository.\n\nKeep in mind that git doesn't really CARE about timestamps to do most\noperations; it operates on the graph created by parentage. Think of the\ntimestamps more as comments; when a commit is created, we comment who\ndid it and when, both accordinging to their local information.\n\n-Peff\n\nPS Nit: Git doesn't work with changesets, it works with snapshots,\nbuilding a directed graph of snapshots. Maybe that is the source of your\nconfusion?\n"},{"id":"27725","messageId":"20060927002745.15344.qmail@web51005.mail.yahoo.com","threadId":"5710","inReplyTo":"20060926233321.GA17084@coredump.intra.peff.net","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-27T00:27:45Z","receivedAt":"2006-09-27T00:27:45Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"> Keep in mind that git doesn't really CARE about timestamps to do most\n> operations; it operates on the graph created by parentage. Think of the\n> timestamps more as comments; when a commit is created, we comment who\n> did it and when, both accordinging to their local information.\n> \n> -Peff\n> \n> PS Nit: Git doesn't work with changesets, it works with snapshots,\n> building a directed graph of snapshots. Maybe that is the source of your\n> confusion\n\nIt's true I don't know much about git, what is the difference between a changeset and a snapshot?\nAre you saying timestamps should be tracked separately or tracked by an scm system built on top of\ngit? Does/should git care about the when of a snapshot?\n\nPerhaps my question is directed more toward gitweb.cgi, it seems to me the timestamp of when a\nsnapshot was merged into this repository should somehow be tracked and that is what gitweb.cgi\nshould default to display. For example, if someone wants to know if security bugfix X was merged\ninto linus' kernel tree they also want to know when that happened, don't they? \n\n-Matt\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27727","messageId":"Pine.LNX.4.63.0609261746160.22495@qynat.qvtvafvgr.pbz","threadId":"5710","inReplyTo":"BAYC1-PASMTP084ACE9B12C54DABFE8EB9AE1A0@CEZ.ICE","subject":"Re: git and time","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-09-27T00:47:27Z","receivedAt":"2006-09-27T00:47:27Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Tue, 26 Sep 2006, Sean wrote:\n\n>> It's true I don't know much about git, what is the difference between a changeset and a snapshot?\n>> Are you saying timestamps should be tracked separately or tracked by an scm system built on top of\n>> git? Does/should git care about the when of a snapshot?\n>>\n>> Perhaps my question is directed more toward gitweb.cgi, it seems to me the timestamp of when a\n>> snapshot was merged into this repository should somehow be tracked and that is what gitweb.cgi\n>> should default to display. For example, if someone wants to know if security bugfix X was merged\n>> into linus' kernel tree they also want to know when that happened, don't they?\n>\n> You are right that a \"Merged Date:\" in gitweb would be useful information to\n> show for each commit, but it's not straightforward given the design of git.\n\nwould it?\n\nremember that a pach could be merged to many trees in any order. which merge \ndate do you want to know about?\n\nDavid Lang\n"},{"id":"27726","messageId":"BAYC1-PASMTP084ACE9B12C54DABFE8EB9AE1A0@CEZ.ICE","threadId":"5710","inReplyTo":"20060927002745.15344.qmail@web51005.mail.yahoo.com","subject":"Re: git and time","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-09-27T00:56:32Z","receivedAt":"2006-09-27T00:56:32Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 26 Sep 2006 17:27:45 -0700 (PDT)\nMatthew L Foster wrote:\n\n\n> It's true I don't know much about git, what is the difference between a changeset and a snapshot?\n> Are you saying timestamps should be tracked separately or tracked by an scm system built on top of\n> git? Does/should git care about the when of a snapshot?\n> \n> Perhaps my question is directed more toward gitweb.cgi, it seems to me the timestamp of when a\n> snapshot was merged into this repository should somehow be tracked and that is what gitweb.cgi\n> should default to display. For example, if someone wants to know if security bugfix X was merged\n> into linus' kernel tree they also want to know when that happened, don't they? \n\nYou are right that a \"Merged Date:\" in gitweb would be useful information to\nshow for each commit, but it's not straightforward given the design of git.\n\nEach commit contains the date and time it was first created. Because this value\nis used as part of each commits' unique hash value, it can not be changed without\nbreaking a very fundamental part of Git. This means that Git can not easily\nanswer the question of which date any particular commit was merged with the\nlocal repository.\n\nTo help address this, the \"reflog\" feature was added (i believe by Shawn Pearce)\nwhich records a local time stamp when pulling in changes from other repositories.\nIt should be possible to query this log to get the information you desire, but I\ndon't think it would be efficient enough to do in gitweb unless the values were\ncached instead of queried each time.\n\nSean\n"},{"id":"27728","messageId":"BAYC1-PASMTP073037545878F6FEB7E88FAE1A0@CEZ.ICE","threadId":"5710","inReplyTo":"Pine.LNX.4.63.0609261746160.22495@qynat.qvtvafvgr.pbz","subject":"Re: git and time","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-09-27T01:07:21Z","receivedAt":"2006-09-27T01:07:21Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 26 Sep 2006 17:47:27 -0700 (PDT)\nDavid Lang wrote:\n\n> would it?\n> \n> remember that a pach could be merged to many trees in any order. which merge \n> date do you want to know about?\n\nI *think* it would be useful information to know when it was merged with the\n_local_ repository. So in the case of kernel.org gitweb, you'd essentially\nbe able to find out when _Linus_ received the commit and published it to the\nworld. Doesn't that sound worthwhile?\n\nSean\n"},{"id":"27729","messageId":"7vodt2nmft.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"20060927002745.15344.qmail@web51005.mail.yahoo.com","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-27T01:11:02Z","receivedAt":"2006-09-27T01:11:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthew L Foster writes:\n\n>> PS Nit: Git doesn't work with changesets, it works with snapshots,\n>> building a directed graph of snapshots. Maybe that is the source of your\n>> confusion\n>\n> It's true I don't know much about git, what is the difference\n> between a changeset and a snapshot? Are you saying timestamps\n> should be tracked separately or tracked by an scm system built\n> on top of git? Does/should git care about the when of a\n> snapshot?\n\nI do not know what Jeff meant by snapshot vs changeset, so I\nwould not comment on this part.\n\n> Perhaps my question is directed more toward gitweb.cgi, it\n> seems to me the timestamp of when a snapshot was merged into\n> this repository should somehow be tracked and that is what\n> gitweb.cgi should default to display. For example, if someone\n> wants to know if security bugfix X was merged into linus'\n> kernel tree they also want to know when that happened, don't\n> they?\n\nEach commit object in git records two timestamps. When the\nauthor made that change, and when the change was made into a\ncommit object in _some_ repository. I _think_ gitweb shows the\nlatter, but I haven't checked, so Jakub is CC'ed.\n\nWhat you want to know, when a particular change has become part\nof the history of one branch in one repository, is not something\na git commit object records. Enough people wanted to know that\ninformation, so ref-log was introduced. When it is enabled on a\nbranch, ref-log records when the tip of the branch changed from\nwhat commit to what other commit. But it primarily is meant to\nanswer this question: \"what commit was at the tip of this branch\nat time T?\"\n\nSo if Linus had enabled ref-log in his public repository, and if\ngitweb knew to look at ref-log, then gitweb _could_ iterate over\nref-log records for the \"master\" branch of Linus's repository,\nfind the earliest one that makes the tip of the \"master\" branch\na descendant of that security fix X, and report the time of that\nchange. It could certainly do that.\n\nI have to warn you that this is fairly expensive, and also I\nhappen to know that Linus does not have ref-log enabled on his\npublic repository.\n\nHaving said that, I doubt the question \"when did Linus's tree\nsaw this security fix X commit?\" has much practical value. For\none thing, the time he merges the side branch that has the\nsecurity fix and the time he pushes out the resulting mess^Wtree\nout to the public repository is different. After pushed out to\nthe public repository, it takes time for that to mirror out for\npublic view. From the consumer's point of view, the time it\nfinishes mirroring out _is_ the only timestamp that matters, but\nthat mirroing happens outside of git so even if ref-log showed\ntimestamp from the repository Linus pushes to, it would not\nreflect the time the general public first saw \"Linus's official\nversion that contained that fix\".\n\nWhat people would often want to know is \"Does v2.6.18-rc5\ninclude that fix?\" which is a similar but different question.\nThis is something gitweb _could_ answer without using ref-log,\nand gitk already knows how to answer it.\n\nI somehow thought that it was possible to get \"the latest tag\nthat precedes this commit\" (aka \"git describe\") for each commit\nby visiting its commitdiff_plain page, but I do not see it now.\nCan somebody tell me if I am hallucinating?\n"},{"id":"27731","messageId":"Pine.LNX.4.63.0609261823540.22495@qynat.qvtvafvgr.pbz","threadId":"5710","inReplyTo":"7vk63qnlc2.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-09-27T01:31:59Z","receivedAt":"2006-09-27T01:31:59Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Tue, 26 Sep 2006, Junio C Hamano wrote:\n\n> David Lang writes:\n>\n>>> You are right that a \"Merged Date:\" in gitweb would be useful information to\n>>> show for each commit, but it's not straightforward given the design of git.\n>>\n>> would it?\n>>\n>> remember that a pach could be merged to many trees in any order. which\n>> merge date do you want to know about?\n>\n> The date that repository I am looking at with gitweb first had\n> that commit, of course. What other dates did you have in mind?\n>\n\nif that repository is then merged into another one, what date would that second \none record for that commit? the date it was pulled there?\n\nin many cases this would seem to be useless or distracting information (you \nalready display where in the history the merge took place, do you really need to \nattach that date to all changes that arrive from the branch?)\n\nif you have something like\n\na-b-c-d-e-f-g\n \\\nh------i------j\n\nor worse\n\n a\n \\\nb-----c-d\n \\ / \\\n e-f-----g\n \\\nh-i---------j\n\ndo you really want the date of j attached to all the changes a-g?\n\nand if this information really is important, wouldn't you want to export the \ninfo out (as j then gets merged into m somewhere else)\n\nDavid Lang\n"},{"id":"27730","messageId":"7vk63qnlc2.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"Pine.LNX.4.63.0609261746160.22495@qynat.qvtvafvgr.pbz","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-27T01:34:53Z","receivedAt":"2006-09-27T01:34:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Lang writes:\n\n>> You are right that a \"Merged Date:\" in gitweb would be useful information to\n>> show for each commit, but it's not straightforward given the design of git.\n>\n> would it?\n>\n> remember that a pach could be merged to many trees in any order. which\n> merge date do you want to know about?\n\nThe date that repository I am looking at with gitweb first had\nthat commit, of course. What other dates did you have in mind?\n"},{"id":"27732","messageId":"BAYC1-PASMTP03770EEC1581564F1E1330AE1A0@CEZ.ICE","threadId":"5710","inReplyTo":"Pine.LNX.4.63.0609261823540.22495@qynat.qvtvafvgr.pbz","subject":"Re: git and time","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-09-27T01:58:36Z","receivedAt":"2006-09-27T01:58:36Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 26 Sep 2006 18:31:59 -0700 (PDT)\nDavid Lang wrote:\n\n> if that repository is then merged into another one, what date would that second \n> one record for that commit? the date it was pulled there?\n\nYes of course. The question being posed and answered is.. when did the local\nrepository first get any specific commit. For the sake of such a question\nits merge history and path into the local repository doesn't matter, only\nwhen the commit arrived locallly.\n\nSean\n"},{"id":"27733","messageId":"Pine.LNX.4.64.0609261849430.3952@g5.osdl.org","threadId":"5710","inReplyTo":"20060927002745.15344.qmail@web51005.mail.yahoo.com","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-27T01:58:48Z","receivedAt":"2006-09-27T01:58:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Sep 2006, Matthew L Foster wrote:\n> \n> It's true I don't know much about git, what is the difference between a \n> changeset and a snapshot?\n\nSome of it is just semantic, but a lot of it has real user-visible meaning \nsimply because of the \"mental model\" difference, so the semantics actually \nhave some meaning.\n\nA lot of systems think of commits as \"what changed\", and thus the \n\"changeset\" mentality. A \"commit\" is just the combination of all changes \nthat that commit introduced.\n\nGit very fundamentally does not think like that at all.\n\nGit thinks of a commit as a _state_, and the history that led up to that \nstate. So instead of the commit actually containing pointers to what \nchanged, it very much contains a pointer directly to the actual state that \nwas committed (a \"tree\" in git parlance), and then a set of pointers to \nthe \"parent\" commits - the commits that explain where we came from.\n\nNow, in some sense, you can ignore the difference between the two models, \nsince you'd think that they are totally equivalent: from the git model, \nyou can always get the \"changeset\" by just diffing the current state with \nthe previous state, and conversely from the \"changeset\" model you can \nalways get the \"current state\" by just applying the changeset to the \nprevious state.\n\nSo in that sense, it's just two different ways of looking at exactly the \nsame thing.\n\nHOWEVER. The fact that git internally thinks in terms of \"snapshots\" means \nthat it makes no sense to (for example) record a \"file rename\". Git \nfigures it out on its own, by just looking at the state before and after. \nThe great thing about that is that the exact same logic actually works \neven for _unconnected_ states/snapshots, in a way that a \"changeset\" based \nsituation would find very hard.\n\nSo this is when the otherwise semantic difference actually shows itself. \nYou can diff between two arbitrary points in time, and git will figure out \nrenames on its own, without actually ever looking at the changesets in \nbetween (in fact, there may not even _be_ a straight, unbroken chain of \nchangesets between the two states).\n\n> Are you saying timestamps should be tracked separately or tracked by an \n> scm system built on top of git? Does/should git care about the when of a \n> snapshot?\n\nGit does record the timestamp, but it records it in the same way it \nrecords the \"username\" - in that it doesn't really _matter_ to git. It \nnever actually affects any meaning (well, since you can query for it, it \nhas a meaning of sorts, but it's strictly limited to any explicit queries, \nso if you do \"git log --since=2.weeks.ago\" it will use the timestamp to \ngive you what you want, but it doesn't actually affect anything \nimportant).\n\nSo think of the timestamps as just comments with a very specific format.\n\n\t\tLinus\n"},{"id":"27734","messageId":"7vhcyukpkc.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"Pine.LNX.4.63.0609261823540.22495@qynat.qvtvafvgr.pbz","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-27T02:31:47Z","receivedAt":"2006-09-27T02:31:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Lang writes:\n\n>>> remember that a pach could be merged to many trees in any order. which\n>>> merge date do you want to know about?\n>>\n>> The date that repository I am looking at with gitweb first had\n>> that commit, of course. What other dates did you have in mind?\n>\n> if that repository is then merged into another one, what date would\n> that second one record for that commit? the date it was pulled there?\n>\n> in many cases this would seem to be useless or distracting information\n> (you already display where in the history the merge took place, do you\n> really need to attach that date to all changes that arrive from the\n> branch?)\n\nUsually, but not on fast forward.\n\nOnly when somebody is interested in the particular question\n\"when did this commit has become part of this branch\" it becomes\nrelevant. And do not get me wrong. I am in principle agreeing\nwith you that this is an extra information for most of the time\n-- I even doubt \"when did this commit has become part of this\nbranch\" is all that useful.\n"},{"id":"27741","messageId":"BAYC1-PASMTP037BE64D8E979289EE7D68AE1A0@CEZ.ICE","threadId":"5710","inReplyTo":"7vhcyukpkc.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-09-27T02:41:33Z","receivedAt":"2006-09-27T02:41:33Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 26 Sep 2006 19:31:47 -0700\nJunio C Hamano wrote:\n\n> Only when somebody is interested in the particular question\n> \"when did this commit has become part of this branch\" it becomes\n> relevant. And do not get me wrong. I am in principle agreeing\n> with you that this is an extra information for most of the time\n> -- I even doubt \"when did this commit has become part of this\n> branch\" is all that useful.\n\nIt is interesting information for some people though. For instance\nsomeone wondering how long ago Linus published a certain security fix.\nTo be able to say to easily query gitweb and be able to report,\n\"Linus published that security fix X day ago etc..\"\n\nOf course, I agree with you that also knowing the revision number\nsuch a commit appeared in is at least if not more important. But\nstill I don't dismiss this date/time based question as completely\nas you do. The very fact that a gitweb user has brought this issue\nforward (and this isn't the first time) suggests the information\nis at least of casual interest to some people.\n\nSean\n"},{"id":"27749","messageId":"20060927033459.GA27622@coredump.intra.peff.net","threadId":"5710","inReplyTo":"20060927002745.15344.qmail@web51005.mail.yahoo.com","subject":"Re: git and time","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-09-27T03:34:59Z","receivedAt":"2006-09-27T03:34:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 26, 2006 at 05:27:45PM -0700, Matthew L Foster wrote:\n\n> It's true I don't know much about git, what is the difference between\n> a changeset and a snapshot?\n\nI think Linus' explanation covered what I meant, but please ask for\nclarification if there was something that didn't make sense.\n\n> Are you saying timestamps should be tracked separately or tracked by\n> an scm system built on top of git? Does/should git care about the\n> when of a snapshot?\n\nYes, they could be tracked separately. My point was that git deals in\nimmutable snapshot objects (commits) and you don't want to change the\ncommit objects after the fact. You could certainly make an external\nmapping of \"this commit object entered the repo at local time T\" but I\ndoubt it would be of much use. See below.\n\n> Perhaps my question is directed more toward gitweb.cgi, it seems to me\n> the timestamp of when a snapshot was merged into this repository\n> should somehow be tracked and that is what gitweb.cgi should default\n> to display. For example, if someone wants to know if security bugfix X\n> was merged into linus' kernel tree they also want to know when that\n> happened, don't they?\n\nRight. So you really want to know not \"when did this commit enter this\nrepo\" but rather \"when did this head/branch first contain this commit\"\n(since there may be multiple branches within a repo). We can find out\n\"does commit X contain commit Y\" by looking at the commit graph. The\nreflog system records \"head H contained commit X at time T\" so between\nthe two you can find the answer to your question (but it takes some\ncomputation).\n\nI think Junio's email explained this better than I could, but again,\nplease ask if something is unclear.\n\n-Peff\n"},{"id":"27751","messageId":"BAYC1-PASMTP0819E6B1CBE028BD171598AE1A0@CEZ.ICE","threadId":"5710","inReplyTo":"20060927033459.GA27622@coredump.intra.peff.net","subject":"Re: git and time","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-09-27T03:43:09Z","receivedAt":"2006-09-27T03:43:09Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 26 Sep 2006 23:34:59 -0400\nJeff King wrote:\n\n> Right. So you really want to know not \"when did this commit enter this\n> repo\" but rather \"when did this head/branch first contain this commit\"\n> (since there may be multiple branches within a repo).\n\nEven though it's being a bit pedantic, I have to disagree with you here.\nThe question the user is asking is exactly, \"When did this commit enter\n_this_ repo?\".\n\nBecause of the design of git, such a question must be converted into a\nquestion regarding reflogs and head/branch values etc... But the user\ndoesn't care anything about all that. They're just interested in the\ndate/time the commit was published in the repository in question, not\nthe date time the commit was originally created in some distant\nrepo.\n\nSean\n"},{"id":"27752","messageId":"20060927042850.GB9460@spearce.org","threadId":"5710","inReplyTo":"20060926234309.b16aa44e.seanlkml@sympatico.ca","subject":"Re: git and time","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-27T04:28:50Z","receivedAt":"2006-09-27T04:28:50Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sean wrote:\n> On Tue, 26 Sep 2006 23:34:59 -0400\n> Jeff King wrote:\n> \n> > Right. So you really want to know not \"when did this commit enter this\n> > repo\" but rather \"when did this head/branch first contain this commit\"\n> > (since there may be multiple branches within a repo).\n> \n> Even though it's being a bit pedantic, I have to disagree with you here.\n> The question the user is asking is exactly, \"When did this commit enter\n> _this_ repo?\".\n> \n> Because of the design of git, such a question must be converted into a\n> question regarding reflogs and head/branch values etc... But the user\n> doesn't care anything about all that. They're just interested in the\n> date/time the commit was published in the repository in question, not\n> the date time the commit was originally created in some distant\n> repo.\n\nAnd with the completely distributed nature of Git I have to say\nthat's a useful question to get an answer to. Though I believe\nJunio pointed out that may be incorrect by several hours for\nLinus' public tree due to the mirroring that occurs on kernel.org.\nHowever so long as the existance of that lag is publically stated\nI don't really see a problem.\n\nAs Junio correctly pointed out answering that question is rather\ncompute intensive (as Git things go) as you need to compare both\nthe reflog for the branch in question (or all branches!) against\nthe commit chain(s) and find where that commit became visible.\nNot cheap certainly but possible with the data we have.\n\n\nHowever people are ignoring the fact that receive-pack doesn't\nupdate the reflog. As of current `next` its *still* doing the ref\nupdates by hand, rather than going through the common library code\nin refs.c. As a consequence its bypassing the reflog implementation.\nThis means that `git-push` does not update the reflog. Which means\nthere's no way Linus' public repository could have a reflog.\n\nMaybe if I (or someone else) fixed receive-pack.c Linus might\nconsider enabling reflog, and maybe someone could fix gitweb.cgi to\nperform the computation - but possibly server owners wouldn't want\nthat feature running due to its high computation cost. Especially\nif gitweb.cgi doesn't have a native C executable to do most of the\nwork for it.\n\nFor what its worth I keep meaning to get around to fix receive-pack.c\nbut I just haven't done it yet.\n\n-- \nShawn.\n"},{"id":"27753","messageId":"7v3badkj4k.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"BAYC1-PASMTP0819E6B1CBE028BD171598AE1A0@CEZ.ICE","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-27T04:50:51Z","receivedAt":"2006-09-27T04:50:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sean writes:\n\n> On Tue, 26 Sep 2006 23:34:59 -0400\n> Jeff King wrote:\n>\n>> Right. So you really want to know not \"when did this commit enter this\n>> repo\" but rather \"when did this head/branch first contain this commit\"\n>> (since there may be multiple branches within a repo).\n>\n> Even though it's being a bit pedantic, I have to disagree with you here.\n> The question the user is asking is exactly, \"When did this commit enter\n> _this_ repo?\".\n>\n> Because of the design of git, such a question must be converted into a\n> question regarding reflogs and head/branch values etc... But the user\n> doesn't care anything about all that. They're just interested in the\n> date/time the commit was published in the repository in question, not\n> the date time the commit was originally created in some distant\n> repo.\n\nI disagree.\n\nFor somebody who is tracking my \"master\" branch, it does not\nmatter when some critical fix appeared on my \"next\" branch. The\nuser will be vulnerable until that fix makes its way to the\n\"master\" branch. The user _can_ switch to track my \"next\"\nbranch, but that is like arguing that the user can apply the\nsame patch to his local copy that tracks my \"master\".\n\nI may try-pull from Paul to get updates from gitk, but usually I\ndo that with \"git fetch\", not \"git pull\". So my repository may\ncontain commits and blobs for the latest and greatest gitk, but\nuntil I merge it and push the result out nobody would benefit\nfrom it through my repository.\n\nSee? Having a commit somewhere in the repository does not make\nany difference unless that commit is on some branches you care\nabout.\n"},{"id":"27754","messageId":"7vy7s5j4fb.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"20060927042850.GB9460@spearce.org","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-27T04:53:44Z","receivedAt":"2006-09-27T04:53:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> For what its worth I keep meaning to get around to fix receive-pack.c\n> but I just haven't done it yet.\n\nI've been futzing around that code because I wanted to make sure\nwe get the locking right on creation and deletion of refs. I'll\ntry to remember when I revisit the code tomorrow.\n"},{"id":"27756","messageId":"BAYC1-PASMTP07B3618F64E47E873F2379AE1A0@CEZ.ICE","threadId":"5710","inReplyTo":"7v3badkj4k.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-09-27T05:04:37Z","receivedAt":"2006-09-27T05:04:37Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Tue, 26 Sep 2006 21:50:51 -0700\nJunio C Hamano wrote:\n\n> For somebody who is tracking my \"master\" branch, it does not\n> matter when some critical fix appeared on my \"next\" branch. The\n> user will be vulnerable until that fix makes its way to the\n> \"master\" branch. The user _can_ switch to track my \"next\"\n> branch, but that is like arguing that the user can apply the\n> same patch to his local copy that tracks my \"master\".\n> \n> I may try-pull from Paul to get updates from gitk, but usually I\n> do that with \"git fetch\", not \"git pull\". So my repository may\n> contain commits and blobs for the latest and greatest gitk, but\n> until I merge it and push the result out nobody would benefit\n> from it through my repository.\n> \n> See? Having a commit somewhere in the repository does not make\n> any difference unless that commit is on some branches you care\n> about.\n\nWell, yes. And all of my examples have assumed the example of\nLinus' repository where there is only one branch. So yes, in the\ncase where there are more than one branch, you want to be able\nto ask the more specific question, when did this commit arrive\ninto this repo-branch.\n\nBut that is really the minutia of the issue. First we have to\nagree that users _do_ want to know the date of commits beyond\njust those recorded inside the commit itself.\n\nIf we do agree on that point, then the rest is just the details\nof how plausible it is to provide those answers. Shawn has made\nit clear that the reflog doesn't really have all the information\nwe need yet. On top of which it would be expensive to compute\netc.\n\nSean\n"},{"id":"27761","messageId":"20060927055216.GA28490@coredump.intra.peff.net","threadId":"5710","inReplyTo":"20060927010437.5fa57ed0.seanlkml@sympatico.ca","subject":"Re: git and time","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-09-27T05:52:16Z","receivedAt":"2006-09-27T05:52:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 27, 2006 at 01:04:37AM -0400, Sean wrote:\n\n> Well, yes. And all of my examples have assumed the example of\n> Linus' repository where there is only one branch. So yes, in the\n> case where there are more than one branch, you want to be able\n> to ask the more specific question, when did this commit arrive\n> into this repo-branch.\n\nYes, that is what I was trying to point out by making the branch/repo\ndistinction in my previous mail.\n\n> If we do agree on that point, then the rest is just the details\n> of how plausible it is to provide those answers. Shawn has made\n> it clear that the reflog doesn't really have all the information\n> we need yet. On top of which it would be expensive to compute\n> etc.\n\nWe should be able to make a naive space-time tradeoff: whenever a ref is\nupdated from X to Y at time T, for each commit C in X..Y, mark the tuple\n(ref, C) with time T. Assuming a reasonably packed format (20 bytes of\nSHA1, 4 bytes of time, sorted into .git/time-cache/master) the git\nrepository would require less than 1M per branch. Updating the ref\nbecomes much more expensive, but looking up the value is quite cheap.\n\nOf course, rewinding would make this more complicated. I'm still not\nconvinced this approach is worth the effort.\n\n-Peff\n"},{"id":"27762","messageId":"BAYC1-PASMTP04CC69006B1B0728D73152AE1A0@CEZ.ICE","threadId":"5710","inReplyTo":"20060927055216.GA28490@coredump.intra.peff.net","subject":"Re: git and time","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-09-27T06:15:29Z","receivedAt":"2006-09-27T06:15:29Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 27 Sep 2006 01:52:16 -0400\nJeff King wrote:\n\n> Yes, that is what I was trying to point out by making the branch/repo\n> distinction in my previous mail.\n\nYeah, Junio's response made me realize that. Apologies.\n\n> We should be able to make a naive space-time tradeoff: whenever a ref is\n> updated from X to Y at time T, for each commit C in X..Y, mark the tuple\n> (ref, C) with time T. Assuming a reasonably packed format (20 bytes of\n> SHA1, 4 bytes of time, sorted into .git/time-cache/master) the git\n> repository would require less than 1M per branch. Updating the ref\n> becomes much more expensive, but looking up the value is quite cheap.\n\nYes. It should be relatively straight forward, and removes the need to\nuse the reflog at all. It's the right tradeoff since the value would\nbe queried much more often than updated.\n \n> Of course, rewinding would make this more complicated. I'm still not\n> convinced this approach is worth the effort.\n\nYou could almost ignore rewinding without too big a problem, or at least\nonly deal with it when performing a prune.\n\nAs for being worth the effort, we'll have to see if anyone steps up to\nactually offer a patch. If not, you're right again :o)\n\nSean\n"},{"id":"27776","messageId":"451A398C.3060800@op5.se","threadId":"5710","inReplyTo":"7vodt2nmft.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-09-27T08:42:52Z","receivedAt":"2006-09-27T08:42:52Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Matthew L Foster writes:\n> \n>>> PS Nit: Git doesn't work with changesets, it works with snapshots,\n>>> building a directed graph of snapshots. Maybe that is the source of your\n>>> confusion\n>> It's true I don't know much about git, what is the difference\n>> between a changeset and a snapshot? Are you saying timestamps\n>> should be tracked separately or tracked by an scm system built\n>> on top of git? Does/should git care about the when of a\n>> snapshot?\n> \n> I do not know what Jeff meant by snapshot vs changeset, so I\n> would not comment on this part.\n> \n\nMe neither, but I've seen this distinction before on the mailing-list.\n\nTo my mind, a changeset is the patch that brings some form of data from \none state (snapshot) to another. In this respect, git is certainly both \nsnapshot- and changeset-based.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"27781","messageId":"7vfyedd3bw.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"20060927042850.GB9460@spearce.org","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-27T10:13:55Z","receivedAt":"2006-09-27T10:13:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> However people are ignoring the fact that receive-pack doesn't\n> update the reflog. As of current `next` its *still* doing the ref\n> updates by hand, rather than going through the common library code\n> in refs.c.\n\nThis is unfortunately on top of many things, but judging from\nthe number of deleted lines and added lines, I think it is going\nin the right direction.\n\nOne thing that makes \"the common library code\" less useful is\nthat lock_ref_sha1() and its cousin lock_any_ref_for_update() do\nnot let the caller to tell why a ref could not be locked (\"did\nit not exist? did the old_sha1 not match?\" and in\nlock_ref_sha1()'s case \"did the ref have funny characters?\").\n\n-- >8 --\n[PATCH] Teach receive-pack about ref-log\n\nThis converts receive-pack to use the standard ref locking code\ninstead of its own. As a side effect, it automatically records\nthe \"push\" event to ref-log if enabled.\n\nSigned-off-by: Junio C Hamano \n---\n receive-pack.c | 88 ++++++++++----------------------------------------------\n 1 files changed, 15 insertions(+), 73 deletions(-)\n\ndiff --git a/receive-pack.c b/receive-pack.c\nindex abbcb6a..f0b4cb4 100644\n--- a/receive-pack.c\n+++ b/receive-pack.c\n@@ -41,34 +41,6 @@ struct command {\n \n static struct command *commands;\n \n-static int is_all_zeroes(const char *hex)\n-{\n-\tint i;\n-\tfor (i = 0; i < 40; i++)\n-\t\tif (*hex++ != '0')\n-\t\t\treturn 0;\n-\treturn 1;\n-}\n-\n-static int verify_old_ref(const char *name, char *hex_contents)\n-{\n-\tint fd, ret;\n-\tchar buffer[60];\n-\n-\tif (is_all_zeroes(hex_contents))\n-\t\treturn 0;\n-\tfd = open(name, O_RDONLY);\n-\tif (fd < 0)\n-\t\treturn -1;\n-\tret = read(fd, buffer, 40);\n-\tclose(fd);\n-\tif (ret != 40)\n-\t\treturn -1;\n-\tif (memcmp(buffer, hex_contents, 40))\n-\t\treturn -1;\n-\treturn 0;\n-}\n-\n static char update_hook[] = \"hooks/update\";\n \n static int run_update_hook(const char *refname,\n@@ -105,8 +77,8 @@ static int update(struct command *cmd)\n \tconst char *name = cmd->ref_name;\n \tunsigned char *old_sha1 = cmd->old_sha1;\n \tunsigned char *new_sha1 = cmd->new_sha1;\n-\tchar new_hex[60], *old_hex, *lock_name;\n-\tint newfd, namelen, written;\n+\tchar new_hex[41], old_hex[41];\n+\tstruct ref_lock *lock;\n \n \tcmd->error_string = NULL;\n \tif (!strncmp(name, \"refs/\", 5) && check_ref_format(name + 5)) {\n@@ -115,59 +87,27 @@ static int update(struct command *cmd)\n \t\t\t name);\n \t}\n \n-\tnamelen = strlen(name);\n-\tlock_name = xmalloc(namelen + 10);\n-\tmemcpy(lock_name, name, namelen);\n-\tmemcpy(lock_name + namelen, \".lock\", 6);\n-\n \tstrcpy(new_hex, sha1_to_hex(new_sha1));\n-\told_hex = sha1_to_hex(old_sha1);\n+\tstrcpy(old_hex, sha1_to_hex(old_sha1));\n \tif (!has_sha1_file(new_sha1)) {\n \t\tcmd->error_string = \"bad pack\";\n \t\treturn error(\"unpack should have generated %s, \"\n \t\t\t \"but I can't find it!\", new_hex);\n \t}\n-\tsafe_create_leading_directories(lock_name);\n-\n-\tnewfd = open(lock_name, O_CREAT | O_EXCL | O_WRONLY, 0666);\n-\tif (newfd < 0) {\n-\t\tcmd->error_string = \"can't lock\";\n-\t\treturn error(\"unable to create %s (%s)\",\n-\t\t\t lock_name, strerror(errno));\n-\t}\n-\n-\t/* Write the ref with an ending '\\n' */\n-\tnew_hex[40] = '\\n';\n-\tnew_hex[41] = 0;\n-\twritten = write(newfd, new_hex, 41);\n-\t/* Remove the '\\n' again */\n-\tnew_hex[40] = 0;\n-\n-\tclose(newfd);\n-\tif (written != 41) {\n-\t\tunlink(lock_name);\n-\t\tcmd->error_string = \"can't write\";\n-\t\treturn error(\"unable to write %s\", lock_name);\n-\t}\n-\tif (verify_old_ref(name, old_hex) < 0) {\n-\t\tunlink(lock_name);\n-\t\tcmd->error_string = \"raced\";\n-\t\treturn error(\"%s changed during push\", name);\n-\t}\n \tif (run_update_hook(name, old_hex, new_hex)) {\n-\t\tunlink(lock_name);\n \t\tcmd->error_string = \"hook declined\";\n \t\treturn error(\"hook declined to update %s\", name);\n \t}\n-\telse if (rename(lock_name, name) < 0) {\n-\t\tunlink(lock_name);\n-\t\tcmd->error_string = \"can't rename\";\n-\t\treturn error(\"unable to replace %s\", name);\n-\t}\n-\telse {\n-\t\tfprintf(stderr, \"%s: %s -> %s\\n\", name, old_hex, new_hex);\n-\t\treturn 0;\n+\n+\tlock = lock_any_ref_for_update(name, old_sha1);\n+\tif (!lock) {\n+\t\tcmd->error_string = \"failed to lock\";\n+\t\treturn error(\"failed to lock %s\", name);\n \t}\n+\twrite_ref_sha1(lock, new_sha1, \"push\");\n+\n+\tfprintf(stderr, \"%s: %s -> %s\\n\", name, old_hex, new_hex);\n+\treturn 0;\n }\n \n static char update_post_hook[] = \"hooks/post-update\";\n@@ -318,9 +258,11 @@ int main(int argc, char **argv)\n \tif (!dir)\n \t\tusage(receive_pack_usage);\n \n-\tif(!enter_repo(dir, 0))\n+\tif (!enter_repo(dir, 0))\n \t\tdie(\"'%s': unable to chdir or not a git archive\", dir);\n \n+\tgit_config(git_default_config);\n+\n \twrite_head_info();\n \n \t/* EOF */\n-- \n1.4.2.1.gf80a\n"},{"id":"27789","messageId":"20060927140918.65775.qmail@web51004.mail.yahoo.com","threadId":"5710","inReplyTo":"7vodt2nmft.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-27T14:09:18Z","receivedAt":"2006-09-27T14:09:18Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\n> Each commit object in git records two timestamps. When the\n> author made that change, and when the change was made into a\n> commit object in _some_ repository. \n\nPerhaps git should record three(+) timestamps, adding when the change was committed into this\nrepository? Last weekend there was a committ in Linus' kernel tree with a timestamp ~2 days into\nthe future, which could be a problem in a scenario involving when an important bug fix was\nmerged/published in Linus' kernel tree, situations like that should be impossible. How can git be\nsaid to keep an accurate record of history if time is uncertain?\n\n-Matt\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27790","messageId":"451A8AD9.2010107@op5.se","threadId":"5710","inReplyTo":"20060927140918.65775.qmail@web51004.mail.yahoo.com","subject":"Re: git and time","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-09-27T14:29:45Z","receivedAt":"2006-09-27T14:29:45Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthew L Foster wrote:\n> How can git be\n> said to keep an accurate record of history if time is uncertain?\n> \n\nBecause git doesn't care about timestamps. It stores them as comments \n(albeit auto-formatted comments) and relies on the dependency chain to \nprovide history.\n\nIn the same way that contributors are expected to write clear and \nconcise commit-messages, they are also expected to keep their system \nclocks somewhat in sync. Sometimes one or the other fails, and this is \nas inevitable as it can be annoying (although commit-messages along the \nline of \"fixed some bugs causing some random crashes\" for a commit that \ntouches 2384 lines are indefinitely worse than a bad timestamp).\n\nWhat's beautiful about git is that it's designed to present a correct \nhistory even if random-contributor-X's system clock is out of sync with \nthe rest of the world, as it inevitably will be at one point or another. \nIt handles content, and the order in which each piece of content was \nadded/removed/mutilated/transformed into something else, and it does a \ngood job at that.\n\nAll that aside though, would you rather have that fix pronto with a bad \ntimestamp, or three days later when the contributor had time to set up \nntp properly?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"27791","messageId":"20060927151102.GC20705@spearce.org","threadId":"5710","inReplyTo":"7vfyedd3bw.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-27T15:11:02Z","receivedAt":"2006-09-27T15:11:02Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> One thing that makes \"the common library code\" less useful is\n> that lock_ref_sha1() and its cousin lock_any_ref_for_update() do\n> not let the caller to tell why a ref could not be locked (\"did\n> it not exist? did the old_sha1 not match?\" and in\n> lock_ref_sha1()'s case \"did the ref have funny characters?\").\n\nYes. But I thought that in all such cases we use error or die so\nthe message is sent to STDERR before the process either terminates\nor the function returns NULL. So although the caller doesn't know\nwhy the lock failed the end user does.\n\nGit hasn't exactly structured its error messages in the past.\nIf we are talking about going down the path of having functions\nreturn why they failed to the caller so the caller can react to\nthe failure as they see fit then we've got some work to do. :)\n\n> diff --git a/receive-pack.c b/receive-pack.c\n> @@ -318,9 +258,11 @@ int main(int argc, char **argv)\n> \tif (!dir)\n> \t\tusage(receive_pack_usage);\n> \n> -\tif(!enter_repo(dir, 0))\n> +\tif (!enter_repo(dir, 0))\n> \t\tdie(\"'%s': unable to chdir or not a git archive\", dir);\n> \n\nYou are missing:\n+\tsetup_ident();\n\nWithout that reflog can't get the proper committer data from the\nhost's gecos information. This is probably what is desired for\nmost pushes over SSH.\n\n> +\tgit_config(git_default_config);\n> +\n> \twrite_head_info();\n\n-- \nShawn.\n"},{"id":"27794","messageId":"20060927152847.GA2807@coredump.intra.peff.net","threadId":"5710","inReplyTo":"451A398C.3060800@op5.se","subject":"Re: git and time","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-09-27T15:28:47Z","receivedAt":"2006-09-27T15:28:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 27, 2006 at 10:42:52AM +0200, Andreas Ericsson wrote:\n\n> >>It's true I don't know much about git, what is the difference\n> >>between a changeset and a snapshot? Are you saying timestamps\n> >\n> >I do not know what Jeff meant by snapshot vs changeset, so I\n> >would not comment on this part.\n>\n> Me neither, but I've seen this distinction before on the mailing-list.\n> \n> To my mind, a changeset is the patch that brings some form of data from \n> one state (snapshot) to another. In this respect, git is certainly both \n> snapshot- and changeset-based.\n\nI was talking specifically about the core data structure of git. The\ncommit object doesn't say \"I'm based on commit X, and the deltas are Y.\"\nIt says \"Here are the complete contents of the tree at this point, and\nthe previous complete contents were X.\"\n\nOf course, git often shows changesets (patches, git-whatchanged, etc)\nbecause that's what's useful to users. But the context of the discussion\nwas fetching commits to a repository. In that case it's important to\nnote that you're just grabbing the new state (albeit optimizing the\nprocess by skipping things you have) and not \"re-committing\" changesets\n(which is what the OP seemed to think was happening).\n\n-Peff\n"},{"id":"27796","messageId":"Pine.LNX.4.64.0609270919220.3952@g5.osdl.org","threadId":"5710","inReplyTo":"20060927140918.65775.qmail@web51004.mail.yahoo.com","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-27T16:29:22Z","receivedAt":"2006-09-27T16:29:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 27 Sep 2006, Matthew L Foster wrote:\n> \n> Perhaps git should record three(+) timestamps, adding when the change was committed into this\n> repository?\n\nIf you ask for logging, that's exactly what you get.\n\nWell, almost. \n\nYou cannot connect the time to a _commit_, since a commit (very much by \ndesign) is totally immutable. Once you have created any git object, it's \ndone. It can never be changed ever again, and this is not just a small \ndetail, it's what the whole system builds up on, and it's where the \nsecurity and trustworthiness fundamentally comes from (it's also where the \nnaming scheme comes from - things are named by their contents, so if you \nwere to ever change them again, they'd have to be renamed - they \neffectively _become_ something different).\n\nAlso, you fundamentally couldn't do it anyway, since the third time isn't \nactually even well-defined in a distributed manner. It only makes sense \nvery much in a local way, and as such can never be part of the distributed \ndata - and trying to add something like that to the commit would be \nfundamentally incorrect.\n\nBUT.\n\nWhat you CAN do is to connect (in any particular private repository) a \n_branch_update_ with the time it was done. That is Shawn Pierces \"reflog\" \nwork - you can track a particular branch _locally_. It's purely local to \nthat _one_ repository, though. It by definition makes no sense anywhere \nelse, and it's not tracking commits, it's literally tracking how branches \nchanged in a local copy.\n\nTo enable it, just add a\n\n\t[core]\n\t\tlogAllRefUpdates=true\n\nthing to your .git/config file (or, if you want to do it for _all_ the \nprojects you track, you can just do it in your ~/.gitconfig file, and it \nshould be the default for everything you do).\n\n(Althernatively, you can choose to log just a _single_ branch by just \ncreating the \".git/logs/refs/heads/\" file - git should start \nlogging that branch automatically)\n\nThis is a reasonably new feature, so old git versions need not apply.\n\n\t\t\tLinus\n"},{"id":"27800","messageId":"20060927200054.7a49b619.froese@gmx.de","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609270919220.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Edgar Toernig","fromEmail":"froese@gmx.de","sentAt":"2006-09-27T18:00:54Z","receivedAt":"2006-09-27T18:00:54Z","isPatch":false,"sender":{"key":"froese@gmx.de","avatar":null},"body":"Linus Torvalds wrote:\n>\n> On Wed, 27 Sep 2006, Matthew L Foster wrote:\n> > \n> > Perhaps git should record three(+) timestamps, adding when the change was committed into this\n> > repository?\n> \n> What you CAN do is to connect (in any particular private repository) a \n> _branch_update_ with the time it was done. That is Shawn Pierces \"reflog\" \n> work - you can track a particular branch _locally_. It's purely local to \n> that _one_ repository, though. It by definition makes no sense anywhere \n> else, and it's not tracking commits, it's literally tracking how branches \n> changed in a local copy.\n\nWell, I would simply look at the filesystem's mtime of the commit object\nresp. the pack containing the commit. IMHO good enough most of the time.\n\nCiao, ET.\n"},{"id":"27801","messageId":"20060927180147.33024.qmail@web51009.mail.yahoo.com","threadId":"5710","inReplyTo":"451A8AD9.2010107@op5.se","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-27T18:01:47Z","receivedAt":"2006-09-27T18:01:47Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"> Because git doesn't care about timestamps. It stores them as comments \n> (albeit auto-formatted comments) and relies on the dependency chain to \n> provide history.\n\nOk, the word \"history\" in the context of git primarily means the order of changes not the when?\nWould it be a conceptual or technical issue for git to directly track the local time of\nmerges/changesets?\n\n-Matt\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27802","messageId":"Pine.LNX.4.64.0609271105430.3952@g5.osdl.org","threadId":"5710","inReplyTo":"20060927200054.7a49b619.froese@gmx.de","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-27T18:09:18Z","receivedAt":"2006-09-27T18:09:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 27 Sep 2006, Edgar Toernig wrote:\n> \n> Well, I would simply look at the filesystem's mtime of the commit object\n> resp. the pack containing the commit. IMHO good enough most of the time.\n\nNope. The moment you repack, you're toast. And if you don't repack, please \ndon't use large repositories.\n\nHere's a real-world example: in the week since 2.6.18 was released, the \nkernel has gotten over twenty _thousand_ new objects. If you don't repack, \nyou'll have lost about 40MB of diskspace. It adds up.\n\nSo yes, mtime works for a bit. And then it stops working ;)\n\n\t\tLinus\n"},{"id":"27803","messageId":"Pine.LNX.4.64.0609271109510.3952@g5.osdl.org","threadId":"5710","inReplyTo":"20060927180147.33024.qmail@web51009.mail.yahoo.com","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-27T18:10:33Z","receivedAt":"2006-09-27T18:10:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 27 Sep 2006, Matthew L Foster wrote:\n> \n> Ok, the word \"history\" in the context of git primarily means the order of changes not the when?\n> Would it be a conceptual or technical issue for git to directly track the local time of\n> merges/changesets?\n\nTrue merges _get_ tracked - they are commits too (they just have multiple \nparents).\n\nBut it's only the time the merge was done that gets tracked, not the time \nthe merge was then pushed out to somebody else.\n\n\t\tLinus\n"},{"id":"27804","messageId":"451AC88E.1060104@shadowen.org","threadId":"5710","inReplyTo":"20060927180147.33024.qmail@web51009.mail.yahoo.com","subject":"Re: git and time","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-09-27T18:53:02Z","receivedAt":"2006-09-27T18:53:02Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Matthew L Foster wrote:\n>> Because git doesn't care about timestamps. It stores them as comments \n>> (albeit auto-formatted comments) and relies on the dependency chain to \n>> provide history.\n> \n> Ok, the word \"history\" in the context of git primarily means the order of changes not the when?\n> Would it be a conceptual or technical issue for git to directly track the local time of\n> merges/changesets?\n\nIt is tracking the local times of each change as it is added to the\ndependancy chain. This chain then moves about between repositories\ncarrying its stamp with it. When we merge a set of changes into a trunk\nsuch as Linus does that merge will be stamped by him saying when he\nmerged it. So there is plenty of time stuff in there.\n\nOf course none of it tells you when the kernel you are running has it\nin. The only way to know that is to know when the thing was released,\nunder what version#, and what version you are running.\n\nNow when we make a signed tag, doen't that make a new object too and I\nassume that has a tagged date in it. That time might really actually\nmean something and a fix's relation ship to those tags might also mean\nsomething.\n\n-apw\n"},{"id":"27813","messageId":"20060927204428.39120.qmail@web51014.mail.yahoo.com","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609271109510.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-27T20:44:28Z","receivedAt":"2006-09-27T20:44:28Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Linus Torvalds wrote:\n\n> > Ok, the word \"history\" in the context of git primarily means the order of changes not the\n> when?\n> > Would it be a conceptual or technical issue for git to directly track the local time of\n> > merges/changesets?\n> \n> True merges _get_ tracked - they are commits too (they just have multiple \n> parents).\n> \n> But it's only the time the merge was done that gets tracked, not the time \n> the merge was then pushed out to somebody else.\n\nWhat is the difference between a merge and a \"merge then pushed out\"? There are at least some\nsituations where a repo would prefer to know its local time of a merge or pulled in merge and\nanyway a local repo probably should not in any way be dependent on nor _trust_ all remote repos\ntimestamps...?\n\n-Matt\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27814","messageId":"7v1wpx9gwk.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"20060927151102.GC20705@spearce.org","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-27T20:46:35Z","receivedAt":"2006-09-27T20:46:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> You are missing:\n> +\tsetup_ident();\n>\n> Without that reflog can't get the proper committer data from the\n> host's gecos information. This is probably what is desired for\n> most pushes over SSH.\n\nWhat's even more interesting is when there is .git/config file\nand you do not override it with environment variables; the log\nentry will be made under the name of the repository user.name in\nsuch a case.\n\n>> +\tgit_config(git_default_config);\n>> +\n>> \twrite_head_info();\n\nOften setup_ident() needs to go together with git_config(), and\nyou need to remember that setup must come before config. These\nrules are a bit cumbersome to follow and I often forget.\n\nI wonder if we can have a simpler start-up sequence perhaps to\navoid future mistakes like this?\n"},{"id":"27815","messageId":"Pine.LNX.4.64.0609271347060.3952@g5.osdl.org","threadId":"5710","inReplyTo":"20060927204428.39120.qmail@web51014.mail.yahoo.com","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-27T20:51:39Z","receivedAt":"2006-09-27T20:51:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 27 Sep 2006, Matthew L Foster wrote:\n> \n> What is the difference between a merge and a \"merge then pushed out\"? There are at least some\n> situations where a repo would prefer to know its local time of a merge or pulled in merge and\n> anyway a local repo probably should not in any way be dependent on nor _trust_ all remote repos\n> timestamps...?\n\nLook into the ref-logging. It's exactly what you ask for.\n\nThe fact is, in a distributed system, you can _never_ make sense of \n\"time\". Just live with it. That's basic \"distributed programming 101\", and \nit's the one thing every such course should start with on the very first \nday.\n\nSo in short, you _cannot_ depend on time in a distributed environment. \nReally. Stop even asking. Please.\n\nYou can ask when some local reference was changed, and we support that \nalready, and I pointed you to how to enable it in a repository you care \nabout. But it's _always_ going to be just about your local repository, the \nwhole question doesn't make sense any other way.\n\nAnd no, it's _never_ going to tag individual merges or commits, since the \nsame merge or commit can show up at DIFFERENT times in different branches, \neven within the same local repository.\n\nSo as long as you continue to ask for \"commit times\", you cannot get what \nyou ask for. The _only_ commit time that makes sense is the time ON THE \nMACHINE that the commit was made. That's the time that git already saves \nin the commit itself. And if you don't trust that timeframe, then tough \nluck.\n\nGit itself doesn't trust it, because git knows better. But it's there.\n\n\t\tLinus\n"},{"id":"27816","messageId":"Pine.LNX.4.64.0609271354480.3952@g5.osdl.org","threadId":"5710","inReplyTo":"20060927204428.39120.qmail@web51014.mail.yahoo.com","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-27T21:01:54Z","receivedAt":"2006-09-27T21:01:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 27 Sep 2006, Matthew L Foster wrote:\n> \n> What is the difference between a merge and a \"merge then pushed out\"?\n\nTo answer just this technical question, which came up today:\n\n - I might do a merge at 8:30 in the morning, but since I do it on my \n machine, and nobody else actually saw my merge.\n\n - at 9:30, somebody sends me a patch that I already have (through the \n merge), and I reply saying \"I got this already\", but I realize I \n haven't pushed it out.\n\n - so I replicate my home machine tree to the one on master.kernel.org, \n and now others can see it.\n\nWhen did the merge happen? It happened at 8:30 on my machine, and that's \nwhat is recorded. End of story. No ifs, buts, maybes about it. That's the \nonly time you can _ever_ see for that merge.\n\nWhen did everybody else see it? It only became _visible_ in the git \narchive on kernel.org at 9:30, when I pushed out _all_ the merges that I \nhad done (some of them at 8:30, others at 8:00, yet others perhaps at some \nother time).\n\nSo all those different merges, which were done at different times, only \nbecame visible in another git repository all at the same time, at 9:30.\n\nThere's _zero_ commits or merges that themselves happened at 9:30. There's \nno development at all that happened then. The only actual thing that \nchanged at 9:30 was that the _reference_ that made all those old changes \nvisible finally made it to the repository at kernel.org.\n\nThis is why you can use the ref-logging code to say \"Ok, how did my \nrepository look at 9:25 vs 9:35\" and you could see the difference. BUT NO \nACTUAL COMMIT OR MERGE WILL EVER HAVE THAT TIMESTAMP. That's purely a \n\"when did it show up\" question, and the whole question only makes sense \nwithin a particular repository (ie the answers are different: on _my_ \nmachine, a merge showed up on 8:30 when it was made. On other machines, \nthe time will always be different).\n\n\t\tLinus\n"},{"id":"27818","messageId":"20060927211643.82491.qmail@web51015.mail.yahoo.com","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609271347060.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-27T21:16:43Z","receivedAt":"2006-09-27T21:16:43Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Linus Torvalds wrote:\n\n> The fact is, in a distributed system, you can _never_ make sense of \n> \"time\". Just live with it. That's basic \"distributed programming 101\", and \n> it's the one thing every such course should start with on the very first \n> day.\n\nI agree which is exactly why I think git should conceptually prefer a repo's _local_ time. \n\nCommit/merge times could be specific to each repo and not generally distributed? \n \n-Matt\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27819","messageId":"20060927213607.GA21839@spearce.org","threadId":"5710","inReplyTo":"7v1wpx9gwk.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-27T21:36:07Z","receivedAt":"2006-09-27T21:36:07Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Shawn Pearce writes:\n> \n> > You are missing:\n> > +\tsetup_ident();\n> >\n> > Without that reflog can't get the proper committer data from the\n> > host's gecos information. This is probably what is desired for\n> > most pushes over SSH.\n> \n> What's even more interesting is when there is .git/config file\n> and you do not override it with environment variables; the log\n> entry will be made under the name of the repository user.name in\n> such a case.\n\nYes. :-)\n\nShared repository owners might want to not set user.name in their\nconfig files.\n\nAnother way around this would be to create a variation of\ngit_default_config for use in receive-pack.c that doesn't recognize\nuser.name/user.email.\n \n> >> +\tgit_config(git_default_config);\n> >> +\n> >> \twrite_head_info();\n> \n> Often setup_ident() needs to go together with git_config(), and\n> you need to remember that setup must come before config. These\n> rules are a bit cumbersome to follow and I often forget.\n> \n> I wonder if we can have a simpler start-up sequence perhaps to\n> avoid future mistakes like this?\n\nI think most places we are \"starting up\" we invoke both, in that\norder. Which sort of implies maybe we could just fold setup_ident\ninto git_config.\n\n-- \nShawn.\n"},{"id":"27820","messageId":"20060927214417.36420.qmail@web51002.mail.yahoo.com","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609271354480.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-27T21:44:16Z","receivedAt":"2006-09-27T21:44:16Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Linus Torvalds wrote:\n\n> - so I replicate my home machine tree to the one on master.kernel.org, \n> and now others can see it.\n> \n> When did the merge happen? It happened at 8:30 on my machine, and that's \n> what is recorded. End of story. No ifs, buts, maybes about it. That's the \n> only time you can _ever_ see for that merge.\n\nOk, so it's more complex because of the workflow issue of delayed/pseudo mirroring/replication\nbetween private and public repos? This cloning/replication is not done through git? Are you saying\nit's impossible for master.kernel.org's git to track the local time of each\ncommit/merge/replication? Perhaps replication time is precisely what should/could be tracked\n(locally)? \n\n>From an integrity or at least gitweb.cgi's viewpoint it seems very important to me that commit\norder also be per repo consistent with time order.\n\n-Matt\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27821","messageId":"Pine.LNX.4.64.0609271446160.3952@g5.osdl.org","threadId":"5710","inReplyTo":"20060927214417.36420.qmail@web51002.mail.yahoo.com","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-27T21:48:03Z","receivedAt":"2006-09-27T21:48:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 27 Sep 2006, Matthew L Foster wrote:\n> > When did the merge happen? It happened at 8:30 on my machine, and that's \n> > what is recorded. End of story. No ifs, buts, maybes about it. That's the \n> > only time you can _ever_ see for that merge.\n> \n> Ok, so it's more complex because of the workflow issue of delayed/pseudo mirroring/replication\n> between private and public repos? This cloning/replication is not done through git?\n\nNo, it very much happened with git.\n\nBut git will _refuse_ to rewrite history. That means that if a commit says \nit happened at 8:30AM on machine X, git will _not_ rewrite history to say \nthat it happened at 9:30AM on machine Y just because that's when it made \nit to that machine.\n\n> Are you saying it's impossible for master.kernel.org's git to track the \n> local time of each commit/merge/replication?\n\nNo, I'm saying that that would be _lying_.\n\nThe actual action happened at 8:30. And git tracks only truth. It doesn't \nrewrite the truth afterwards.\n\n\t\tLinus\n"},{"id":"27822","messageId":"20060927215612.GB21839@spearce.org","threadId":"5710","inReplyTo":"20060927214417.36420.qmail@web51002.mail.yahoo.com","subject":"Re: git and time","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-27T21:56:12Z","receivedAt":"2006-09-27T21:56:12Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Matthew L Foster wrote:\n> --- Linus Torvalds wrote:\n> \n> > - so I replicate my home machine tree to the one on master.kernel.org, \n> > and now others can see it.\n> > \n> > When did the merge happen? It happened at 8:30 on my machine, and that's \n> > what is recorded. End of story. No ifs, buts, maybes about it. That's the \n> > only time you can _ever_ see for that merge.\n> \n> Ok, so it's more complex because of the workflow issue of delayed/pseudo mirroring/replication\n> between private and public repos?\n\nNo. Its no different than anything else. Linus' personal repository\nis just as visible to you as say Andrew Morton's personal repository\n(read: neither one is visible to you). Therefore the date/time\nthat a given commit hits either one of those repositories is only\nof interest to the people with direct access to it. Which is Linus\nand Andrew respectively. And probably nobody else.\n\nWhen Linus pushes all of those merges out to kernel.org those\ncommits are arriving at \"his\" kernel.org repository at a date/time\nthat is absolutely after when they first arrived in Linus' personal\nrepository. Note that the kernel.org repository is a completely\ndifferent repository from Linus' personal work repository!\n\nBut due to clock skew, time zone differences, etc. between systems\nthose commits may actually appear to arrive at kernel.org before,\nat the same time as, or after they arrived on Linus' personal system.\n:-)\n\n> This cloning/replication is not done through git?\n\nI don't know. I'd wager Linus is probably using Git to push changes\nto some repository on a master system behind the kernel.org domain\nname, and that master then gets replicated out to mirror systems\nthrough some form of replication.\n\n> Are you saying it's impossible for master.kernel.org's git to track the local time of each\n> commit/merge/replication? Perhaps replication time is precisely what should/could be tracked\n> (locally)? \n\nI don't think the replication time is really important here. If it\nwas then Git should be used for the replication of Git repositories\nbeing mirrored on kernel.org. I doubt you'd get every mirror\noperator to do that however.\n\n> From an integrity or at least gitweb.cgi's viewpoint it seems very important to me that commit\n> order also be per repo consistent with time order.\n\nI'm not sure I follow you. Time order has nothing to do with\nanything. That's largely been the entire point of this thread.\n\nBecause of the potentical for clock skew even on a single system\nyou can't take much stock in a timestamp. But with Git you can at\nleast completely trust the commit graph, provided that you trust\nthose who made commits before your own commit. Of course this\ntrust is only possible because the commit graph cannot be altered\nonce a node has been added into it.\n\nAs such the commit graph is consistent between repositories (assuming\nthey have the same head commits), but the timestamps of the reflogs\nwithin each will widely differ. They could widely differ even on\nthe same system due to ntpd updating the clock at the exact wrong\nmoment for example. :)\n\n-- \nShawn.\n"},{"id":"27823","messageId":"20060927222854.82278.qmail@web51014.mail.yahoo.com","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609271446160.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-27T22:28:54Z","receivedAt":"2006-09-27T22:28:54Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Linus Torvalds wrote:\n\n> The actual action happened at 8:30. And git tracks only truth. It doesn't \n> rewrite the truth afterward.\n\nSo the separate action of replication is not tracked? Replication/sub merges are denied the\npossibility of \"truth\"?\n\nTo be clear I think there are actually two separate though semi-related issues:\n\n- 1. release/replication time of a mirrored private --> public repo\n\n- 2. A repo's commit order being inconsistent with local time order\n\nMy questions are primarily focused on #2. Last weekend even your private repo's commit order was\nout of sync with your local time order because a remote git server's time was grossly\nmisconfigured, right? Integrity wise that shouldn't happen. I am merely asking if tracking\ncommits/merges using local repo time could solve both issues? If the local merge time information\nis already available in the ref-log then gitweb.cgi might only need to be made aware of it.\n\n-Matt\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27824","messageId":"20060927224651.26627.qmail@web51013.mail.yahoo.com","threadId":"5710","inReplyTo":"20060927215612.GB21839@spearce.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-27T22:46:51Z","receivedAt":"2006-09-27T22:46:51Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Shawn Pearce wrote:\n\n> Because of the potentical for clock skew even on a single system\n> you can't take much stock in a timestamp. But with Git you can at\n> least completely trust the commit graph, provided that you trust\n> those who made commits before your own commit. Of course this\n> trust is only possible because the commit graph cannot be altered\n> once a node has been added into it.\n> \n> As such the commit graph is consistent between repositories (assuming\n> they have the same head commits), but the timestamps of the reflogs\n> within each will widely differ. They could widely differ even on\n> the same system due to ntpd updating the clock at the exact wrong\n> moment for example. :)\n\nI am not arguing for git to try to achieve \"exact\" time just merely locally time consistent commit\norder. This might all just be a gitweb.cgi time display issue, it should be more impossible for a\ncommit to appear as being made 2 days in the future and impossible for local time order to be out\nof sync with commit order. If each git repo used local time to track commits/merges you wouldn't\nhave to worry if any remote git server's time was grossly misconfigured. Time doesn't need to be\nexact, all I am saying is each git repo should trust/prefer its local time rather than a remote\ngit server's timestamp.\n\n-Matt\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27826","messageId":"Pine.LNX.4.64.0609271545140.3952@g5.osdl.org","threadId":"5710","inReplyTo":"20060927222854.82278.qmail@web51014.mail.yahoo.com","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-27T22:54:46Z","receivedAt":"2006-09-27T22:54:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 27 Sep 2006, Matthew L Foster wrote:\n>\n> So the separate action of replication is not tracked?\n\nCorrect. Replication without changes is a no-op.\n\n> Replication/sub merges are denied the possibility of \"truth\"?\n\nNo, it's actually much deeper than that.\n\nTo git, pure replication simply isn't an action at all, so trying to track \nit would be like trying to track all the voices in my head - something \nthat doesn't exist. It wouldn't be \"truth\", it would be insanity.\n\nAnd the thing is, _not_ tracking it is really fundamental. If you actually \ntrack the issue of copying a git repository, you'd end up in a technically \nuntenable and insane situation. You could never \"merge\" two git trees ever \nagain without going into an infinite bouncing back-and-forth of \"A merged \nthe changes from B\" and \"B merged the fact that A merged the changes from \nB\" and \"A merged the fact that B merged the fact that A merged the changes \nfrom B\" and so on ad infinitum.\n\nThere's another reason too, namely that if you track where things came \nfrom and when, suddenly it matters whether you cloned from the _original_ \nrepository or from somewhere else. And that's also fundamnetally wrong, \nsince I don't actually want to give _anybody_ access to the actual \noriginal repository on my machine, so everything always has to go through \nan intermediate repository. If we tracked that, we'd just confuse \neverything, and it wouldn't be seamless any more.\n\nThere's one final reason, namely that I wanted to design git to just track \n_contents_. So the design philosophy is very much against tracking exactly \nwhich repository something has been in, since that has nothing to do with \nthe deeper issue of what you are actually tracking.\n\n\t\tLinus\n"},{"id":"27827","messageId":"20060927225738.GC21839@spearce.org","threadId":"5710","inReplyTo":"20060927224651.26627.qmail@web51013.mail.yahoo.com","subject":"Re: git and time","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-27T22:57:38Z","receivedAt":"2006-09-27T22:57:38Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Matthew L Foster wrote:\n> --- Shawn Pearce wrote:\n> \n> > Because of the potentical for clock skew even on a single system\n> > you can't take much stock in a timestamp. But with Git you can at\n> > least completely trust the commit graph, provided that you trust\n> > those who made commits before your own commit. Of course this\n> > trust is only possible because the commit graph cannot be altered\n> > once a node has been added into it.\n> > \n> > As such the commit graph is consistent between repositories (assuming\n> > they have the same head commits), but the timestamps of the reflogs\n> > within each will widely differ. They could widely differ even on\n> > the same system due to ntpd updating the clock at the exact wrong\n> > moment for example. :)\n> \n> I am not arguing for git to try to achieve \"exact\" time just merely locally time consistent commit\n> order. This might all just be a gitweb.cgi time display issue, it should be more impossible for a\n> commit to appear as being made 2 days in the future and impossible for local time order to be out\n> of sync with commit order. If each git repo used local time to track commits/merges you wouldn't\n> have to worry if any remote git server's time was grossly misconfigured. Time doesn't need to be\n> exact, all I am saying is each git repo should trust/prefer its local time rather than a remote\n> git server's timestamp.\n\nGit does has local time order, so long as the user doesn't screw\naround with their clock.\n\nEach time a commit gets made (or a merge gets performed) Git takes\nthe local system clock and dumps into the new commit as part of\nthe \"committer\" comment. But as has been stated many times before\nin this thread, this is no more trustworthy than the username and\nemail address also appearing in that \"committer\" line and its not\nrelied upon by Git. Some interfaces may try to sort based on this\ntimestamp but only to help it break ties. The dependency graph\nalways wins as that's always correct.\n\nI have a Git repository from which I'm tracking an SVN repository.\nRecently that SVN repository gave me \"(no date)\" as a datestamp.\nGit converted that to Jan 1, 1970. That commit has a parent and\nhas a child, both of which have sane timestamps. But viewing this\nin gitk or git log its obvious that the Jan 1, 1970 commit is in\nthe right position within the graph, it just has a timestamp that\nI can't trust as its 36 years in the past.\n\nThere's nothing I can do about that timestamp. It came from another\nsystem that I have no control over. But Git accurately recorded\nwhat that other system provided it. The \"truth\" here is that other\nsystem provided a bogus timestamp.\n\n-- \nShawn.\n"},{"id":"27828","messageId":"20060927230256.GD21839@spearce.org","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609271545140.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-27T23:02:56Z","receivedAt":"2006-09-27T23:02:56Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> \n> \n> On Wed, 27 Sep 2006, Matthew L Foster wrote:\n> >\n> > So the separate action of replication is not tracked?\n> \n> Correct. Replication without changes is a no-op.\n\nI think it could be reasonably argued that knowing when the head(s)\nof your public repository on a mirror of kernel.org changed to a\ngiven value is useful. Especially when there is a mirroring lag.\n\n-- \nShawn.\n"},{"id":"27829","messageId":"Pine.LNX.4.64.0609271606050.3952@g5.osdl.org","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609271545140.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-27T23:14:24Z","receivedAt":"2006-09-27T23:14:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 27 Sep 2006, Linus Torvalds wrote:\n> \n> No, it's actually much deeper than that.\n> \n> To git, pure replication simply isn't an action at all, so trying to track \n> it would be like trying to track all the voices in my head - something \n> that doesn't exist. It wouldn't be \"truth\", it would be insanity.\n\nAnother reason it's not an action at all: git in many ways does not \nactually care at all about the difference of a \"local branch\" and a \n\"remote branch on another host\".\n\nOf course there _is_ a difference, in that the remote branch has to be \nfetched from that other repository, but it's possible (and some of the \noriginal design came from this) to share the repository data between \nmultiple separate repositories. They can even be on different machines, if \nthere is a networked filesystem in between (and, unlike most systems, the \ngit database format should even be happy about _disconnected_ networked \nfilesystems).\n\nSo git from the ground up is designed so that there is no real difference \nbetween \"remote branch\" and \"local branch\", other than simply physically \nwhere the data might be.\n\nBy that token, \"cloning\" a repository is pretty much by definition a \nno-op as far as the repository contents is concerned. In fact, if you use \n\"git clone -l -s\", all the cost is just checking out the new copy (so if \nyou add \"-n\" to avoid checking out the new state, you basically have a \nzero-cost clone).\n\n\t[torvalds@g5 ~]$ time git clone -n -l -s v2.6/linux empty-clone\n\n\treal 0m0.129s\n\tuser 0m0.084s\n\tsys 0m0.048s\n\nThat's it. I created a \"clone\" of the whole kernel repo in 0.129 seconds.\n\nExactly because cloning doesn't actually _do_ something (of course, 0.129 \nseconds in git speak is pretty slow, so I suspect we are doing something \nstupid here with shell-script).\n\n\t\tLinus\n"},{"id":"27834","messageId":"20060928001241.62887.qmail@web51013.mail.yahoo.com","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609271606050.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T00:12:41Z","receivedAt":"2006-09-28T00:12:41Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\nIgnoring the separate issue of replication for a momment, can someone respond to my time integrity\nquestion about whether a future version of git could trust/prefer its local time rather than a\nremote/sub/parent (non replicated) git server's timestamp? How do we fix gitweb.cgi, ref-log? How\nuseful is gitweb.cgi if timestamps are all over the place? It does not make sense that commit\norder is currently out of sync with time order in the main linux kernel tree git repo on\nkernel.org. Why must each and every repo be dependent on time being set properly on all other git\nservers? How useful is change history or commit order without some concept of (local) time order?\n\n-Matt \n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27836","messageId":"20060928002124.GA16634@coredump.intra.peff.net","threadId":"5710","inReplyTo":"20060928001241.62887.qmail@web51013.mail.yahoo.com","subject":"Re: git and time","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-09-28T00:21:24Z","receivedAt":"2006-09-28T00:21:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 27, 2006 at 05:12:41PM -0700, Matthew L Foster wrote:\n\n> Ignoring the separate issue of replication for a momment, can someone\n> respond to my time integrity question about whether a future version\n> of git could trust/prefer its local time rather than a\n> remote/sub/parent (non replicated) git server's timestamp?\n\nYes, it could. But it would not involve rewriting the commit object or\nadding a new commit object (for reasons I hope have been adequately\nexplained by Linus). Instead, an external mapping would be made between\na commit SHA1 and a timestamp (or a (branch,sha1) pair and a timestamp).\n\nIn fact, this is how reflogs work (but they make a map only when the\nhead changes, not marking each commit that enters the repo).\n\n> How do we fix gitweb.cgi, ref-log?\n\nTo \"fix\" gitweb, keep a database in each local repository as described\nabove (either based on reflog, or one that is more comprehensive). Have\ngitweb report that date rather than the timestamp contained in the\ncommit.\n\nNobody has created such a patch; you can always try and see what the\nresponse is.\n\n> How useful is gitweb.cgi if timestamps are all over the place? It does\n\nQuite useful, according to many git users.\n\n-Peff\n"},{"id":"27839","messageId":"20060928002327.GA22593@spearce.org","threadId":"5710","inReplyTo":"20060928001241.62887.qmail@web51013.mail.yahoo.com","subject":"Re: git and time","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-28T00:23:27Z","receivedAt":"2006-09-28T00:23:27Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Matthew L Foster wrote:\n> \n> Ignoring the separate issue of replication for a momment, can someone respond to my time integrity\n> question about whether a future version of git could trust/prefer its local time rather than a\n> remote/sub/parent (non replicated) git server's timestamp? How do we fix gitweb.cgi, ref-log? How\n> useful is gitweb.cgi if timestamps are all over the place? It does not make sense that commit\n> order is currently out of sync with time order in the main linux kernel tree git repo on\n> kernel.org. Why must each and every repo be dependent on time being set properly on all other git\n> servers? How useful is change history or commit order without some concept of (local) time order?\n\nDependency order is all that matters.\n\nIt doesn't matter if K. Hacker makes a bug fix at 8 am his local\ntime or 3 days ago. All that matters is that K. Hacker made it by\nchanging version A to version B. Therefore commit B (containing\nthe bug fix) depends on commit A and only commit A (which may in\nturn depend on commit A^, etc.).\n\nThat dependency in turn implies that you can't have bug fix B without\nwhatever feature/bug fix was A, and what that dependend on, etc.\nThus you know you have some particular chain of events as a result\nof having B. That's all that's interesting.\n\n\nIt _may_ matter to me that I received commit B (and maybe commit A)\nat 3 pm my local time. It may not.\n\nIn general I don't care too much about when a commit comes to me and\nwhen it doesn't or when it was written, though I do look at\n\n\tgit log next@{yesterday}..next\n\nto see what Junio has pushed out recently. Since I tend to\nfetch only once per day (and usually around the same time of day)\nthis works reasonably well.\n\n-- \nShawn.\n"},{"id":"27845","messageId":"7vzmck7pis.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"20060928001241.62887.qmail@web51013.mail.yahoo.com","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-28T01:23:23Z","receivedAt":"2006-09-28T01:23:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthew L Foster writes:\n\n> Ignoring the separate issue of replication for a momment, can\n> someone respond to my time integrity question about whether a\n> future version of git could trust/prefer its local time rather\n> than a remote/sub/parent (non replicated) git server's\n> timestamp?\n\nThis must be a trick question. git does not trust _any_\ntimestamp, so there is no local \"rather than\" remote.\n\nSo, no there is no chance for that.\n\nHaving said that, what Porcelains like gitweb and gitk do are\ncompletely different issue. I already outlined how you can do\nthat using reflog last night, so I am not going to repeat it\nhere. Also Linus stressed that why the \"order that commits\nappeared on a particular branch in one particular repository\" is\nstrictly local issue today at least three times, and I hope\neverybody understood it by now.\n\nAs Shawn said in a nearby thread, in a public and prominent\nrepository like kernel.org repository it may sometimes be\ninteresting and useful to know when each commit became available\non each branch. I am reasonably sure that it would not however\nmake gitweb output easier to read to order its output by that\ntimestamp. Linus pulls from subsystem maintainers all the time\nand one pull may bring in dozens of commits, and they will get\nthe same timestamp if you did so. Actually it is worse than\nthat. He tends to batch, so he would have many such pulls and\npatch applications in his private repository, perhaps over a few\nhour, but the result will be pushed out to kernel.org with one\npush operation. To show the \"truthful\" time, your gitweb would\ngive the timestamp of that push operation for hundreds of\ncommits pushed out during that operation.\n\nI do not personally think that would be useful at all. And I\nhappen to know how expensive to teach gitweb to produce such an\noutput, so I would not seriously suggest anybody to try it.\n\nCan we please close this topic?\n"},{"id":"27846","messageId":"20060928013611.GC7469@thunk.org","threadId":"5710","inReplyTo":"20060928001241.62887.qmail@web51013.mail.yahoo.com","subject":"Re: git and time","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-09-28T01:36:11Z","receivedAt":"2006-09-28T01:36:11Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Sep 27, 2006 at 05:12:41PM -0700, Matthew L Foster wrote:\n> \n> Ignoring the separate issue of replication for a momment, can\n> someone respond to my time integrity question about whether a future\n> version of git could trust/prefer its local time rather than a\n> remote/sub/parent (non replicated) git server's timestamp? \n\nNo, it can't. In order to do that it would have to change the commit,\nand that would be rewriting history.\n\nConsider a more complicated case of replication, where git is used\nexclusively, so that a patch gets commited by developer A, pushed to\ndevice driver maintainer B, which then gets pushed to subsystem\nmaintainer C, which then pushed to Linus's private tree, and then\nLinus pushes it to the publically visible repository. Now assume for\nthe sake of argument that developers A, B, and C all keep publically\nvisible repositories, all of which are accessible via gitweb.cgi, and\nassume for the sake of argument that the patch is pushed exclusively\nvia git. \n\nIn that case, the time that the changeset was made is the time that\ndeveloper A created the commit. That is, of course, the time on his\nlocal machine, which may or may not be accurate. And of course, the\ne-mail address which he gives may or may not be accurate as well.\nThere can be no integrity guarantees because we are not using\ncryptography. There are no time notaries, no public key signatures.\nBoth the time and the author name/e-mail are merely metadata which is\nattached to the patch, and the time, author name/e-mail, and patch are\nhashed together to form a SHA checksum of the commit. So while we\ndon't have any kind of assurance about the time or author e-mail, what\nwe *do* have is an assurance that a commit's name --- which is the SHA\nchecksum --- refers to a specific patch, and with a specific claimed\ntimestamp and claimed e-mail name. So if we refer to a particular\ncommit by that SHA hash value, we do know globally that we are always\nreferring to the same commit. Changing the time would change the SHA\nhash, which would make it impossible for two machines to know whether\nor not a commit is the same or not.\n\nMore to the point, that particular commit will travel from developer\nA, to B, to C, to Linus, to public repository on master.kernel.org.\nDuring that whole time, it is invariant. It cannot change, including\nthe commit timestamp. Now, at each stage, as the patch gets pushed\nalong, all of the information ---- the patch itself, the claimed time,\nand the claimed author date --- are used to evalute the patch and\ndecide whether or not the patch should be pushed higher up the trust\nhierarchy. In Linus, the most important thing which is used is an\nevaluation of the patch itself. If the patch is good, the fact that\nthe commit time might be six months in the past isn't necessarily a\nproblem. \n\nAnd of course, the commit time might be *right*. It could be that\ndeveloper A did do the work six months ago, but merely sat on it for a\nwhile before submitting it to maintainer B, and maybe maintainer B sat\non it because rc1 had passed and he was being a good doobie and not\nforwarding patches on so that tree could stablize, and by the time rc7\nwas released, he had gotten tired of waiting, so pushed it on to\nlieutenant C, and it finally got pushed to Linus after 2.6.18 was\nreleased, many months later. \n\n> How do we fix gitweb.cgi, ref-log? \n> How useful is gitweb.cgi if timestamps are\n> all over the place? It does not make sense that commit order is\n> currently out of sync with time order in the main linux kernel tree\n> git repo on kernel.org. \n\nYour problem is that you are putting too much faith in the time stamp.\nIt's there as a help, but it is no more trustworthy than the author\nname or the patch description --- which is to say, if people in the\ngit hierarchy are happy with the commit, it will get pushed, and if\nthey aren't it won't. And most people don't care about the time; they\ncare about whether the patch is correct. Now, the time is mostly\ncorrect, so if you look at the patch dependencies you can usually\ndetermine when a patch was likely committed to the first local\nrepoistory to within a few hours in all likelihood.\n\nNow, I could imagine a system where every changeset also had metadata\nassociated with it that involved a receipt from a time notary, and a\ndigital signature so that each patch could be cryptographically shown\nto have come form some individual (or at least someone who posses that\nparticular individual's key). This would add a lot more overhead to\nthe SCM, but at least it's theoretically possible. The question is it\nworth it?\n\nAt least within the Linux commmunity, the most important thing is\nwhether or not the patch is good, not whether it is cryptographically\nsigned by some particular developer. And times are considered even\nless important --- and given that a time notary is complex, and\nrequires out of band facilities such as publishing lists of checksums\nand checksums of checksums in publically norepudiable places such as\nclassifie dadds in the New York Times, LA Times, and Washington Post,\nit won't be something which is zero cost, either. And given that no\none cares enough about times to spend that kind of resources, I very\nmuch doubt git will ever support time notary support.\n\n> Why must each and every repo be dependent on\n> time being set properly on all other git servers? \n\nThey don't.\n\n> How useful is change history or commit order without some concept of\n> (local) time order?\n\nVery useful. :-)\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"27847","messageId":"20060928013914.16514.qmail@web51005.mail.yahoo.com","threadId":"5710","inReplyTo":"20060928002327.GA22593@spearce.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T01:39:13Z","receivedAt":"2006-09-28T01:39:13Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\n--- Shawn Pearce wrote:\n\n> Dependency order is all that matters.\n> \n> It doesn't matter if K. Hacker makes a bug fix at 8 am his local\n> time or 3 days ago. All that matters is that K. Hacker made it by\n> changing version A to version B. Therefore commit B (containing\n> the bug fix) depends on commit A and only commit A (which may in\n> turn depend on commit A^, etc.).\n\n>From a web display/generic notion of integrity perspective time order matters to me but it looks\nlike I am the only one. Keeping track of _local_ commit time would not add any dependencies. \n\n-Matt\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27848","messageId":"20060928014811.19568.qmail@web51005.mail.yahoo.com","threadId":"5710","inReplyTo":"7vzmck7pis.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T01:48:11Z","receivedAt":"2006-09-28T01:48:11Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Junio C Hamano wrote:\n\n> This must be a trick question. git does not trust _any_\n> timestamp, so there is no local \"rather than\" remote.\n\nI actually understand that and agree. All I've been saying is it (git or gitweb.cgi) should prefer\nthe local timestamp rather than any \"remote\" timestamps for no other reason than to minimize the\npossibility of timestamps being grossly inaccurate.\n\n-Matt\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27849","messageId":"BAYC1-PASMTP06CEC55B088A0817EB52CBAE1B0@CEZ.ICE","threadId":"5710","inReplyTo":"20060928014811.19568.qmail@web51005.mail.yahoo.com","subject":"Re: git and time","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-09-28T02:04:04Z","receivedAt":"2006-09-28T02:04:04Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 27 Sep 2006 18:48:11 -0700 (PDT)\nMatthew L Foster wrote:\n\n> I actually understand that and agree. All I've been saying is it (git or gitweb.cgi) should prefer\n> the local timestamp rather than any \"remote\" timestamps for no other reason than to minimize the\n> possibility of timestamps being grossly inaccurate.\n\nBut any local time stamp would be a _lie_. The time stamp in the commit records\nwhen it was actually created. And as Junio has pointed out, hundreds of commits\nwill typically arrive in a repo at the exact same time. Your suggestion would\nhave them all showing the exact same time. That's not helpful, and it loses\nimportant factual information.\n\nYou'd lose the information of when that commit was actually _in truth_ created.\nThe vast majority of the time, everyone has their clock set to a reasonable\nvalue and this all just works. In the rare case when someone has their clock\nset seriously out of whack, Git accurately records and reports that fact too.\n\nReally.. this just isn't a problem. Everything in Git continues to work\nexactly as it should. It may be interesting to see when a commit arrived\nlocally, but it shouldn't be a substitute for the _real_ accurate time\nrecorded in each commit that tells us when it was _really_, _in fact_,\n_in truth_ created.\n\nSean\n"},{"id":"27851","messageId":"Pine.LNX.4.64.0609271918350.3952@g5.osdl.org","threadId":"5710","inReplyTo":"20060928013914.16514.qmail@web51005.mail.yahoo.com","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-28T02:21:22Z","receivedAt":"2006-09-28T02:21:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 27 Sep 2006, Matthew L Foster wrote:\n> \n> From a web display/generic notion of integrity perspective time order \n> matters to me but it looks like I am the only one. Keeping track of \n> _local_ commit time would not add any dependencies.\n\nActually, I think one problem here is that anybody why looks at just the \ngitweb interface may not realize how git works.\n\nIf you use gitk as your primary way of learning about a git problem, the \nwhole time issue just goes away, because gitk shows the _real_ \nrelationships so well.\n\nI used gitk in all my initial explanations of git, because it turned a \nfairly abstract \"here, let me explain how it works\" into a \"See? Look at \nthis\" kind of situation.\n\nI think gitweb is great (in a way I have _never_ felt about any of the CVS \nweb interfaces I have ever seen), but gitweb doesn't really explain how \nthings work as well as gitk does.\n\n\t\tLinus\n"},{"id":"27852","messageId":"20060928022917.29678.qmail@web51011.mail.yahoo.com","threadId":"5710","inReplyTo":"20060928013611.GC7469@thunk.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T02:29:17Z","receivedAt":"2006-09-28T02:29:17Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Theodore Tso wrote:\n\n> On Wed, Sep 27, 2006 at 05:12:41PM -0700, Matthew L Foster wrote:\n> > \n> > Ignoring the separate issue of replication for a momment, can\n> > someone respond to my time integrity question about whether a future\n> > version of git could trust/prefer its local time rather than a\n> > remote/sub/parent (non replicated) git server's timestamp? \n> \n> No, it can't. In order to do that it would have to change the commit,\n> and that would be rewriting history.\n\nPerhaps the actual change itself should not contain a \"commit time\", only \"local commit time\"\nshould matter or be tracked locally (if time is tracked/matters any). To repeat from a previous\nmail, I am not saying timestamps (local or other) should be tracked in a git distributed way,\nquite the opposite, local commit time should be tracked locally. \n\nReplication is a separate issue if I understand git any. Please correct me if I misunderstand: the\nkernel.org gitweb.cgi linux repo time inconsistencies happened when Linus pulled into his\n_private_ repo from a remote git server with misconfigured time, _not_ when he later replicated\nthose errant timestamps from his private repo to the public kernel.org one. I don't care nearly as\nmuch about replication not being time aware, I care about a _merge_ from a remote misconfigured\ngit server making timestamps inconsistent with commit order. Using/prefering local time could\nsolve this but perhaps I am the only one that thinks local time is most important.\n\n-Matt\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27855","messageId":"Pine.LNX.4.63.0609271938070.23262@qynat.qvtvafvgr.pbz","threadId":"5710","inReplyTo":"20060928024938.46785.qmail@web51009.mail.yahoo.com","subject":"Re: git and time","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-09-28T02:43:03Z","receivedAt":"2006-09-28T02:43:03Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Wed, 27 Sep 2006, Matthew L Foster wrote:\n\n> --- Sean wrote:\n>\n>> On Wed, 27 Sep 2006 18:48:11 -0700 (PDT)\n>> Matthew L Foster wrote:\n>>\n>>> I actually understand that and agree. All I've been saying is it (git or gitweb.cgi) should\n>> prefer\n>>> the local timestamp rather than any \"remote\" timestamps for no other reason than to minimize\n>> the\n>>> possibility of timestamps being grossly inaccurate.\n>>\n>> But any local time stamp would be a _lie_. The time stamp in the commit records\n>> when it was actually created. And as Junio has pointed out, hundreds of commits\n>> will typically arrive in a repo at the exact same time. Your suggestion would\n>> have them all showing the exact same time. That's not helpful, and it loses\n>> important factual information.\n>\n> How does git ensure that the timestamp in a commit records when it was actually created? I am not\n> saying throw away creation time, just that local time is more preferable and relevant and\n> git/gitweb.cgi should not in any way depend on time being configured correctly on each and every\n> git server. I think users of kernel.org's repo (or web interface) care more about when change X\n> was commited to it than when an author created/emailed change X, but perhaps I am wrong or don't\n> understand git or both.\n\nwhat you are missing is that there is no one true time 'when the change was \ncommited' to record.\n\nthe closest that you can get in a distributed environement is 'when was this \nchange created' and that is the locally defined time on the box that created it \n(or as Ted stated, some much more complicated process requireing network access \nto a certified time server)\n\nafter it has been created it has been commited (on that box). the same change \ncould be commited on 50 other boxes, either by receiving it through git, or by \nreceiving it via other methods.\n\nall 51 of the boxes above are equally important to git. the fact that one or two \nof those boxes happen to have a user named Linus doesn't matter.\n\nhowever, if what you want to know is 'in what order did this change get into the \ntree I am looking at compared to other changes' git can tell you that and what \nit will tell you is accurate, no matter what the clocks are set to on the \nvarious systems.\n\nDavid Lang\n"},{"id":"27853","messageId":"20060928024938.46785.qmail@web51009.mail.yahoo.com","threadId":"5710","inReplyTo":"BAYC1-PASMTP06CEC55B088A0817EB52CBAE1B0@CEZ.ICE","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T02:49:37Z","receivedAt":"2006-09-28T02:49:37Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Sean wrote:\n\n> On Wed, 27 Sep 2006 18:48:11 -0700 (PDT)\n> Matthew L Foster wrote:\n> \n> > I actually understand that and agree. All I've been saying is it (git or gitweb.cgi) should\n> prefer\n> > the local timestamp rather than any \"remote\" timestamps for no other reason than to minimize\n> the\n> > possibility of timestamps being grossly inaccurate.\n> \n> But any local time stamp would be a _lie_. The time stamp in the commit records\n> when it was actually created. And as Junio has pointed out, hundreds of commits\n> will typically arrive in a repo at the exact same time. Your suggestion would\n> have them all showing the exact same time. That's not helpful, and it loses\n> important factual information.\n\nHow does git ensure that the timestamp in a commit records when it was actually created? I am not\nsaying throw away creation time, just that local time is more preferable and relevant and\ngit/gitweb.cgi should not in any way depend on time being configured correctly on each and every\ngit server. I think users of kernel.org's repo (or web interface) care more about when change X\nwas commited to it than when an author created/emailed change X, but perhaps I am wrong or don't\nunderstand git or both. \n\n-Matt\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27854","messageId":"Pine.LNX.4.64.0609272232040.9349@xanadu.home","threadId":"5710","inReplyTo":"20060928022917.29678.qmail@web51011.mail.yahoo.com","subject":"Re: git and time","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-09-28T02:51:55Z","receivedAt":"2006-09-28T02:51:55Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 27 Sep 2006, Matthew L Foster wrote:\n\n> --- Theodore Tso wrote:\n> \n> > On Wed, Sep 27, 2006 at 05:12:41PM -0700, Matthew L Foster wrote:\n> > > \n> > > Ignoring the separate issue of replication for a momment, can\n> > > someone respond to my time integrity question about whether a future\n> > > version of git could trust/prefer its local time rather than a\n> > > remote/sub/parent (non replicated) git server's timestamp? \n> > \n> > No, it can't. In order to do that it would have to change the commit,\n> > and that would be rewriting history.\n> \n> Perhaps the actual change itself should not contain a \"commit time\", \n> only \"local commit time\" should matter or be tracked locally (if time \n> is tracked/matters any). To repeat from a previous mail, I am not \n> saying timestamps (local or other) should be tracked in a git \n> distributed way, quite the opposite, local commit time should be \n> tracked locally.\n\nWhat I think you want and what you should talk about is that you're \ninterested into the \"local appearance time\" for a given commit and not \n\"local commit time\". Using that terminology is probably much less \nconfusing in the GIT world.\n\nTo do so you'll need a GIT command that doesn'T exist yet. Let's call \nit git-local-arrival. It could be defined as follows:\n\nSYNOPSIS\n\n\tgit-local-arrival \n\nDESCRIPTION\n\n\tThe command displays the time when given commit appeared in the \n\tlocal repository.\n\nIs that what you want? That's certainly something _I_ would be \ninterested in. But such a command would have to do some commit graph \nwalking, based on the recorded reflog data, (there is not much \ndocumentation about reflog unfortunately) to find out exactly when given \ncommit actually was fetched into the local repository. While that would \nbe perfectly acceptable to use on your own machine, I don't think it \nwould be a good idea to let gitweb use it due to the computing cost \nrequired.\n\nBut again that's something possible but for which there is currently no \ncode.\n\n[ thinking out loud: maybe git-rev-list could provide that local \n appearance time quite easily though... ]\n\n\nNicolas\n"},{"id":"27856","messageId":"BAYC1-PASMTP01E800F7F176623630BE98AE1B0@CEZ.ICE","threadId":"5710","inReplyTo":"20060928024938.46785.qmail@web51009.mail.yahoo.com","subject":"Re: git and time","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-09-28T03:03:30Z","receivedAt":"2006-09-28T03:03:30Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 27 Sep 2006 19:49:37 -0700 (PDT)\nMatthew L Foster wrote:\n\n> How does git ensure that the timestamp in a commit records when it was actually created? I am not\n> saying throw away creation time, just that local time is more preferable and relevant and\n> git/gitweb.cgi should not in any way depend on time being configured correctly on each and every\n\nThe time stamp held in each Git commit accurately records the system time\nof the machine on which it was created. That's about the only guarantee \noffered.\n\nThe vast majority of the time this accurately records the proper time.\nIn the rare case when the system time is set incorrectly Git will\n\"accurately\" record this value. The good news is that Git continues\nto work without any problem even if this happens. Hopefully, you\ncan put your mind at ease over that issue.\n\n> git server. I think users of kernel.org's repo (or web interface) care more about when change X\n> was commited to it than when an author created/emailed change X, but perhaps I am wrong or don't\n> understand git or both. \n\nWell no, the time each commit was actually created and imported into its\ninitial repository is also interesting to people.\n\nBut I happen to agree with you that it would be nice to _also_ show the\ntime that each commit appeared in the kernel.org repo. Unfortunately, the\nway Git is designed this just isn't easy. In fact, Junio has gone so far\nas to dare everyone not to even try to implement that feature. So we might\njust have to accept that we'll never see that information on kernel.org.\n\nYou will likely become a lot more comfortable with this, the more you get\nto know and use Git. Perhaps playing with gitk is worthwhile, as Linus\nsuggested. Hopefully you can let this issue go, at least until you've\nplayed with git some more.\n\nSean\n"},{"id":"27857","messageId":"Pine.LNX.4.64.0609272252041.9349@xanadu.home","threadId":"5710","inReplyTo":"7vzmck7pis.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-09-28T03:07:35Z","receivedAt":"2006-09-28T03:07:35Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 27 Sep 2006, Junio C Hamano wrote:\n\n> As Shawn said in a nearby thread, in a public and prominent\n> repository like kernel.org repository it may sometimes be\n> interesting and useful to know when each commit became available\n> on each branch. I am reasonably sure that it would not however\n> make gitweb output easier to read to order its output by that\n> timestamp. Linus pulls from subsystem maintainers all the time\n> and one pull may bring in dozens of commits, and they will get\n> the same timestamp if you did so. Actually it is worse than\n> that. He tends to batch, so he would have many such pulls and\n> patch applications in his private repository, perhaps over a few\n> hour, but the result will be pushed out to kernel.org with one\n> push operation. To show the \"truthful\" time, your gitweb would\n> give the timestamp of that push operation for hundreds of\n> commits pushed out during that operation.\n> \n> I do not personally think that would be useful at all. And I\n> happen to know how expensive to teach gitweb to produce such an\n> output, so I would not seriously suggest anybody to try it.\n\nI beg to differ. Such information might be really useful. I agree \nthough that this is an expensive operation and gitweb might not be the \nbest place for it at all.\n\nFor example... some times I look at git-log output and finds about a \ncertain bug fix that was apparently committed a month ago. And \nincidentally I recall having been bitten by that bug not really long \nago, say last week. Although the bug fix was committed _somewhere_ last \nmonth, what I would really want to know is just when _i_ received that \nbug fix in my own repository to determine if it was before or after last \nweek. So if it was before last week then I could conclude that the bug \nfix didn't actually fix my bug. Knowing that it has been committed last \nmonth is absolutely useless to me in this case.\n\n\nNicolas\n"},{"id":"27858","messageId":"20060928032655.GB3650@socrates.priv","threadId":"5710","inReplyTo":"20060928024938.46785.qmail@web51009.mail.yahoo.com","subject":"Re: git and time","fromName":"Tom Prince","fromEmail":"tom.prince@ualberta.net","sentAt":"2006-09-28T03:26:55Z","receivedAt":"2006-09-28T03:26:55Z","isPatch":false,"sender":{"key":"tom.prince@ualberta.net","avatar":"https://gravatar.com/avatar/a0ad19caee7618876339485106ec994f5202505eecd210ba5c0bd869feaa555a?d=mp&s=160"},"body":"On Wed, Sep 27, 2006 at 07:49:37PM -0700, Matthew L Foster wrote:\n> How does git ensure that the timestamp in a commit records when it was\n> actually created?\nGit doesn't try. Git would be perfectly happy if time(2) returned a\nrandom value each time. No part of git uses the time in any meaningful\nway, it just keeps a record of it to display.\n\n> I am not saying throw away creation time, just that local time is more\n> preferable and relevant and git/gitweb.cgi should not in any way\n> depend on time being configured correctly on each and every git\n> server.\ngit and gitweb.cgi DO NOT in any way depend on time being configured\ncorrectly. If some machine has incorrectly configured time, then they\nwill *correctly* display the strange time. \n\n> I think users of kernel.org's repo (or web interface) care\n> more about when change X was commited to it than when an author\n> created/emailed change X, but perhaps I am wrong or don't understand\n> git or both. \nBased on comments on this list, it appears that most people don't aren't\ninterested in when exactly a given change hits kernel.org. Several\npeople have pointed out ways to get at the information you want, but\nnone of have seen a need for the information, and so haven't the\nmotivation to implement.\n\nIt might help if you gave a use case for the information you want. If\nyou give us a problem that you think the information will solve, the\nlist will probably be able to you how to get at the information you\nwant.\n\nI think you have some misconception of how git works. Git is designed to\nnot lose information. Once a commit is created it is immutable,\nregardless of whether the time is wrong, or the author, or the commit\nmessage, or any bugs in the commit. This is a *feature*. It means you\nneed to go out of your way to destroy history.\n\n> -Matt\n\n Tom\n"},{"id":"27859","messageId":"20060928033948.GC3650@socrates.priv","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609272252041.9349@xanadu.home","subject":"Re: git and time","fromName":"Tom Prince","fromEmail":"tom.prince@ualberta.net","sentAt":"2006-09-28T03:39:48Z","receivedAt":"2006-09-28T03:39:48Z","isPatch":false,"sender":{"key":"tom.prince@ualberta.net","avatar":"https://gravatar.com/avatar/a0ad19caee7618876339485106ec994f5202505eecd210ba5c0bd869feaa555a?d=mp&s=160"},"body":"On Wed, Sep 27, 2006 at 11:07:35PM -0400, Nicolas Pitre wrote:\n> I beg to differ. Such information might be really useful. I agree \n> though that this is an expensive operation and gitweb might not be the \n> best place for it at all.\n> \n> For example... some times I look at git-log output and finds about a \n> certain bug fix that was apparently committed a month ago. And \n> incidentally I recall having been bitten by that bug not really long \n> ago, say last week. Although the bug fix was committed _somewhere_ last \n> month, what I would really want to know is just when _i_ received that \n> bug fix in my own repository to determine if it was before or after last \n> week. So if it was before last week then I could conclude that the bug \n> fix didn't actually fix my bug. Knowing that it has been committed last \n> month is absolutely useless to me in this case.\n> \n\nBut even knowing when the commit arrived in your local repository does\nyou no good unless you are compiling every time you pull, in which case,\nthe reflog support on you local machine will give you the information\nyou need. Otherwise, you need to know the name of the commit you were\nrunning when you got bitten by the bug which is a separate issue.\n\n> Nicolas\n\n Tom\n"},{"id":"27860","messageId":"20060928034704.GB22897@spearce.org","threadId":"5710","inReplyTo":"20060928033948.GC3650@socrates.priv","subject":"Re: git and time","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-28T03:47:05Z","receivedAt":"2006-09-28T03:47:05Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Tom Prince wrote:\n> On Wed, Sep 27, 2006 at 11:07:35PM -0400, Nicolas Pitre wrote:\n> > I beg to differ. Such information might be really useful. I agree \n> > though that this is an expensive operation and gitweb might not be the \n> > best place for it at all.\n> > \n> > For example... some times I look at git-log output and finds about a \n> > certain bug fix that was apparently committed a month ago. And \n> > incidentally I recall having been bitten by that bug not really long \n> > ago, say last week. Although the bug fix was committed _somewhere_ last \n> > month, what I would really want to know is just when _i_ received that \n> > bug fix in my own repository to determine if it was before or after last \n> > week. So if it was before last week then I could conclude that the bug \n> > fix didn't actually fix my bug. Knowing that it has been committed last \n> > month is absolutely useless to me in this case.\n> > \n> \n> But even knowing when the commit arrived in your local repository does\n> you no good unless you are compiling every time you pull, in which case,\n> the reflog support on you local machine will give you the information\n> you need. Otherwise, you need to know the name of the commit you were\n> running when you got bitten by the bug which is a separate issue.\n\nWhich is why Git embeds its version number from git-describe as\npart of its build process. So \"git --version\" can give you back\nan identifier.\n\nAnd given that identifier (and the new schooling given to the\nsha1 expression parser) you can easily ask git to determine if the\ngiven bug fix commit was an ancestor of that identifier, or not.\nNo reflog involved and you have your answer.\n\nAs it happens I build and install `next` every time I fetch from\nJunio's public tree. But I never rely on my reflog to associate\nback to a commit; I always use `git --version`.\n\n-- \nShawn.\n"},{"id":"27866","messageId":"7vfyec63jx.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609272232040.9349@xanadu.home","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-28T04:03:14Z","receivedAt":"2006-09-28T04:03:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> What I think you want and what you should talk about is that you're \n> interested into the \"local appearance time\" for a given commit and not \n> \"local commit time\". Using that terminology is probably much less \n> confusing in the GIT world.\n>\n> To do so you'll need a GIT command that doesn'T exist yet. Let's call \n> it git-local-arrival. It could be defined as follows:\n>\n> SYNOPSIS\n>\n> \tgit-local-arrival \n>\n> DESCRIPTION\n>\n> \tThe command displays the time when given commit appeared in the \n> \tlocal repository.\n\nThis should be certainly doable, but local-arrival may not be\ninteresting if the repository has more than one branches. Maybe\n\n\tgit-local-arrival []\n\nwhich defaults to the current branch?\n"},{"id":"27867","messageId":"7vbqp063c9.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609272252041.9349@xanadu.home","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-28T04:07:50Z","receivedAt":"2006-09-28T04:07:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Wed, 27 Sep 2006, Junio C Hamano wrote:\n>\n>> .... He tends to batch, so he would have many such pulls and\n>> patch applications in his private repository, perhaps over a few\n>> hour, but the result will be pushed out to kernel.org with one\n>> push operation. To show the \"truthful\" time, your gitweb would\n>> give the timestamp of that push operation for hundreds of\n>> commits pushed out during that operation.\n>> \n>> I do not personally think that would be useful at all. And I\n>> happen to know how expensive to teach gitweb to produce such an\n>> output, so I would not seriously suggest anybody to try it.\n>\n> I beg to differ. Such information might be really useful. I agree \n> though that this is an expensive operation and gitweb might not be the \n> best place for it at all.\n>\n> For example... some times I look at git-log output and finds about a \n> certain bug fix that was apparently committed a month ago. And \n> incidentally I recall having been bitten by that bug not really long \n> ago, say last week. Although the bug fix was committed _somewhere_ last \n> month, what I would really want to know is just when _i_ received that \n> bug fix in my own repository to determine if it was before or after last \n> week. So if it was before last week then I could conclude that the bug \n> fix didn't actually fix my bug. Knowing that it has been committed last \n> month is absolutely useless to me in this case.\n\nI beg to agree ;-). Being able to inspect a particular commit\nto find out when it hit the branch is probably useful. I do not\nhave much objection to have it on the commit page.\n\nIt is totally a separate matter to use that timestamp to order\nthe commits listed on the shortlog page, which Matthew seemed to\nbe after. I would say that _is_ wasteful and loses more\ninteresting information by listing all several dozen commits\nLinus pushed out the last time with the same timestamps.\n"},{"id":"27885","messageId":"20060928131710.GE7469@thunk.org","threadId":"5710","inReplyTo":"20060927220404.8e216945.seanlkml@sympatico.ca","subject":"Re: git and time","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-09-28T13:17:10Z","receivedAt":"2006-09-28T13:17:10Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Sep 27, 2006 at 10:04:04PM -0400, Sean wrote:\n\n> > I actually understand that and agree. All I've been saying is it\n> > (git or gitweb.cgi) should prefer the local timestamp rather than\n> > any \"remote\" timestamps for no other reason than to minimize the\n> > possibility of timestamps being grossly inaccurate.\n> \n> But any local time stamp would be a _lie_. The time stamp in the\n> commit records when it was actually created. And as Junio has\n> pointed out, hundreds of commits will typically arrive in a repo at\n> the exact same time. Your suggestion would have them all showing\n> the exact same time. That's not helpful, and it loses important\n> factual information.\n\nThere are two issues here. Could a git tree record the local time\nthat each commit entered the repository? Sure. Someone who wanted to\nhack up git so that it created a local db file associating the SHA\nhash name of the commit with when it arrived in its local repository.\nIt would not be part of the \"true\" git repository information, and it\ncould be something which is optional in the sense that if the\ninformation is lost, it's not the end of the world, vis-a-vis correct\ngit functioning.\n\nThe second question, though, is would it be *useful*? Presumably this\nwould be an option, so the user could request to see the time when a\ncommit hit a particular repository, as well as when the commit was\nfirst created --- or perhaps both.\n\nThe problem though is that this could easily get confusing, since it\nadds a distinction (which repository am I talking to?) which normally\ndoesn't exist in git. And it forces us to make explicit things that\nnormally are kept hidden --- such as whether or not Linus does his\nwork directly on the git tree which is exposed by master.kernel.org,\nor whether he does the work on his own local tree, and then pushes the\nchanges to master.kernel.org. \n\nIn git, we believe that all repositories are equal, and that any sense\nthat a particular repository is the \"master\" or the \"mainline\" is\nstrictly speaking, a matter of convention. What Matthew I think is\nasking for is direct support in git for that notion.\n\nSo it *could* be done, but whether or not it is a good idea or worth\nthe complexity is a different question. One could imagine a\ncompletely different protocol, which exported the contents of the\nhypothetical db database described above. So for maintainers that\nwere *important*, and who were willing to make this information\navailable, given a particular SHA hash of a commit, one could ask the\nquestion, \"when did this commit first eneter your repository\"?\n\nMatthew seems hung up on on desperately wanting to know this\ninformation as it relates to a particular repository --- Linus's.\nThis is in fact different from when the commit hit the repository\nwhich is master.kernel.org which is why the local commit times on\nmaster.kernel.org wouldn't be useful. \n\nHOWEVER, if it was judged important enough, and worth the complexity\nthat it would add to git, the ability to track when a commit entered a\nparticular repository and the ability to export it via some kind of\nweb interface certainly be implemented. Linus would then have to\ndecide whether this was information he felt like making available to\ninquisitive seekers wanting to know this sort of info.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"27887","messageId":"Pine.LNX.4.64.0609281029300.9349@xanadu.home","threadId":"5710","inReplyTo":"7vfyec63jx.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-09-28T14:34:56Z","receivedAt":"2006-09-28T14:34:56Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 27 Sep 2006, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > SYNOPSIS\n> >\n> > \tgit-local-arrival \n> >\n> > DESCRIPTION\n> >\n> > \tThe command displays the time when given commit appeared in the \n> > \tlocal repository.\n> \n> This should be certainly doable, but local-arrival may not be\n> interesting if the repository has more than one branches. Maybe\n> \n> \tgit-local-arrival []\n> \n> which defaults to the current branch?\n\nIndeed. I didn't mention it initially because it is really easy to do \nonce you have it working for the current branch. The technical \nchallenge is about making it efficient to find out which reflog entry \nwith a path to given commit is the oldest.\n\n\nNicolas\n"},{"id":"27888","messageId":"20060928145027.26643.qmail@web51011.mail.yahoo.com","threadId":"5710","inReplyTo":"20060928131710.GE7469@thunk.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T14:50:27Z","receivedAt":"2006-09-28T14:50:27Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Theodore Tso wrote:\n\n> In git, we believe that all repositories are equal, and that any sense\n> that a particular repository is the \"master\" or the \"mainline\" is\n> strictly speaking, a matter of convention. What Matthew I think is\n> asking for is direct support in git for that notion.\n\nNo. I merely think git should try harder to ensure that commit order is consistent with time\norder, it really should (somehow) be impossible for git and gitweb.cgi to have commit dates ~2\ndays in the future. I think replication is a separate issue. In a distributed system the only\n\"time\" that makes any sense or is the most relevant in many situations and most importantly is the\nonly thing that can be semi-trusted is local time. \"Creation date\" is basically just random text\nsomeone entered, there is no guarantee and you are tempting inconsistent time order. And git\nshouldn't be so fragile as to need each and every git server to have time set semi-correctly, but\nI guess it's a bigger deal to non-developers as we actually use time and also believe even web\ninterfaces should have consistency and integrity. \n\n-Matt\n\n-Matt\n\n-Matt\n \n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27890","messageId":"451BEA60.9050306@dawes.za.net","threadId":"5710","inReplyTo":"20060928145027.26643.qmail@web51011.mail.yahoo.com","subject":"Re: git and time","fromName":"Rogan Dawes","fromEmail":"discard@dawes.za.net","sentAt":"2006-09-28T15:29:36Z","receivedAt":"2006-09-28T15:29:36Z","isPatch":false,"sender":{"key":"discard@dawes.za.net","avatar":null},"body":"Matthew L Foster wrote:\n> --- Theodore Tso wrote:\n> \n>> In git, we believe that all repositories are equal, and that any sense\n>> that a particular repository is the \"master\" or the \"mainline\" is\n>> strictly speaking, a matter of convention. What Matthew I think is\n>> asking for is direct support in git for that notion.\n> \n> No. I merely think git should try harder to ensure that commit order is consistent with time\n> order, it really should (somehow) be impossible for git and gitweb.cgi to have commit dates ~2\n> days in the future. I think replication is a separate issue. In a distributed system the only\n> \"time\" that makes any sense or is the most relevant in many situations and most importantly is the\n> only thing that can be semi-trusted is local time. \"Creation date\" is basically just random text\n> someone entered, there is no guarantee and you are tempting inconsistent time order. And git\n> shouldn't be so fragile as to need each and every git server to have time set semi-correctly, but\n> I guess it's a bigger deal to non-developers as we actually use time and also believe even web\n> interfaces should have consistency and integrity. \n> \n> -Matt\n> \n\nSee, the confusion here seems to be that you think that not caring about \nthe time attached to a commit for anything more than a heuristic makes \ngit fragile.\n\nI think that the rest of the git developers prefer to see this as a \nfeature that makes git more robust in the face of something that they \nmight not have any control over (or desire to control).\n\nThat said, if *you* are managing a repository, it shouldn't be difficult \nto enforce the kind of rule that you are asking for. Simply implement a \npre-commit hook that checks all commits that will be added to *your* \nrepo to make sure that time is monotonically increasing from the last \ncommit, and that it does not pass \"now\".\n\nSo if you receive a commit from a developer that violates this rule, you \ncan send the commit back to them with a request to fix their system \ntime, and recreate the patch/series.\n\nI just don't think that any of the kernel developers feel the need to \npolice any one else's clocks . . . they're more interested in the \ncontents of the patch.\n\nRegards,\n\nRogan\n"},{"id":"27896","messageId":"7vodt0vux0.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609281029300.9349@xanadu.home","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-28T16:05:15Z","receivedAt":"2006-09-28T16:05:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n>> Nicolas Pitre writes:\n>> \n>> > SYNOPSIS\n>> >\n>> > \tgit-local-arrival \n>> >\n>> > DESCRIPTION\n>> >\n>> > \tThe command displays the time when given commit appeared in the \n>> > \tlocal repository.\n>> \n>> This should be certainly doable, but local-arrival may not be\n>> interesting if the repository has more than one branches. Maybe\n>> \n>> \tgit-local-arrival []\n>> \n>> which defaults to the current branch?\n>\n> Indeed. I didn't mention it initially because it is really easy to do \n> once you have it working for the current branch. The technical \n> challenge is about making it efficient to find out which reflog entry \n> with a path to given commit is the oldest.\n\nPerhaps bisect it like this. This assumes you never rewind the\nbranch in question and the tip already contains the commit in\nquestion.\n\n-- >8 --\n\n#!/bin/sh\n\n. git-sh-setup\ncommit=`git rev-parse \"$1\"` &&\nbranch=\"${2-`git symbolic-ref HEAD`} || exit\n\ncontains () {\n\tcontains=`git merge-base --all $1 $commit`\n\tcase \"$LF$contains$LF\" in\n\t*\"$LF$contains$LF\"*)\n\t\t: ;;\n\t*)\n\t\tfalse ;;\n\tesac\n}\n\nLF='\n'\nscript='{\n\ts/\t.*//\n\tp\n}' ;# strip things after TAB if a TAB exists\nreflog=\"$GIT_DIR/logs/refs/heads/$branch\";\nlo=1;\nhi=`wc -l <$reflog`\nld=$hi\nwhile expr \"$lo\" \\< \"$hi\" >/dev/null\ndo\n\tmi=`expr \\( $hi \\+ $lo \\) / 2`\n\tline=`sed -ne \"$mi$script\" \"$reflog\"`\n\tto=`expr \"$line\" : '[^ ]* \\([^ ]*\\) '`\n\tif contains $to\n\tthen\n\t\tld=$hi\n\t\thi=$mi\n\telse\n\t\tlo=`expr \"$mi\" + 1`\n\tfi\ndone\n\ncase \"$ld\" in\t\n'')\n\techo >&2 Oops\n\texit 1;;\n?*)\t\n\tline=`sed -ne \"$ld$script\" \"$reflog\"`\n\ttime=`expr \"$line\" : '.*> \\([0-9]*\\) '`\n\tzone=`expr \"$line\" : '.*> [0-9]* \\(.[0-9][0-9][0-9][0-9]\\)$'`\n\techo \"$time $zone\"\nesac\n"},{"id":"27904","messageId":"20060928165509.77413.qmail@web51001.mail.yahoo.com","threadId":"5710","inReplyTo":"451BEA60.9050306@dawes.za.net","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T16:55:08Z","receivedAt":"2006-09-28T16:55:08Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\n--- Rogan Dawes wrote:\n\n> I just don't think that any of the kernel developers feel the need to \n> police any one else's clocks . . . they're more interested in the \n> contents of the patch.\n\nI am not saying git should \"police any one else's clocks\", I am saying git should be designed or\nconfigured in such a way, using local time, that it obviates the current reliance on everyone\nelse's clock being set correctly. \n\n-Matt\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27906","messageId":"Pine.LNX.4.64.0609281003070.3952@g5.osdl.org","threadId":"5710","inReplyTo":"20060928165509.77413.qmail@web51001.mail.yahoo.com","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-28T17:11:01Z","receivedAt":"2006-09-28T17:11:01Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Sep 2006, Matthew L Foster wrote:\n> \n> I am not saying git should \"police any one else's clocks\", I am saying git should be designed or\n> configured in such a way, using local time, that it obviates the current reliance on everyone\n> else's clock being set correctly. \n\nMatt!\n\nTHERE IS NO SUCH RELIANCE! NONE.\n\nTrust me. When we say that git ignores time, WE MEAN IT. Git does not rely \non time, git does not use time, git does not CARE!\n\nPlease stop looking at gitweb _immediately_. If you think time has some \nmeaning for git, stop. It doesn't. We've told you over and over and over \nagain that there is absolutely _zero_ reliance on everybody else's clock \nbeing set correctly. The damn clock could go _backwards_, or make huge \njumping purple leaps of imagination, and git wouldn't care.\n\nThe time that git records is purely a random number. It's a random number \nthat _humans_ can choose to care about or not, and it's a random number \nthat git itself uses only in the sense of \"ok, I've got two equal choices, \nlet's toss a coin to select which one I'll look at next\", BUT IT IS A \nRANDOM NUMBER.\n\nPlease.\n\nDownload a local git archive, and run \"gitk\" on that archive. Then _hide_ \nthe time column (just so that it doesn't confuse you), and then _look_ at \nthe leftmost column which shows the CAUSALITY DAG!\n\nTHAT is what git actually cares about. It's the _only_ thing that git \ncares about. Git cares about _causality_, not time. Nothing else matters.\n\nReally. Truly, pretty please, I promise you, cross my heart and hope to \ndie! Scouts honor. Lock it up and throw away the key. It's TRUE.\n\n\t\tLinus\n"},{"id":"27907","messageId":"7vodszuche.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609281003070.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-28T17:28:45Z","receivedAt":"2006-09-28T17:28:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Thu, 28 Sep 2006, Matthew L Foster wrote:\n>> \n>> I am not saying git should \"police any one else's clocks\", I am saying git should be designed or\n>> configured in such a way, using local time, that it obviates the current reliance on everyone\n>> else's clock being set correctly. \n>\n> Matt!\n>\n> THERE IS NO SUCH RELIANCE! NONE.\n>\n> Trust me. When we say that git ignores time, WE MEAN IT. Git does not rely \n> on time, git does not use time, git does not CARE!\n>\n> Please stop looking at gitweb _immediately_. If you think time has some \n> meaning for git, stop. It doesn't. We've told you over and over and over \n> again that there is absolutely _zero_ reliance on everybody else's clock \n> being set correctly. The damn clock could go _backwards_, or make huge \n> jumping purple leaps of imagination, and git wouldn't care.\n\nI think Matthew means (by \"relying\") that everybody's clock must\nbe set correctly in order for us to show the commits in gitweb\nor rev-list output so that their timestamps are monotonically\ndecreasing (because we list things from newer to older). I\nsympathise.\n\nWe order things by causality (i.e. ancestry order), but that\nunfortunately (!!) happens to match timestamp order for simple\nhistory made on a single machine. This can easily lead to such\na misunderstanding that we are somehow trying to show things in\nlinear time order, hence we subscribe to the notion of global,\nuniform and monotonic time.\n\nOf course, we don't.\n"},{"id":"27908","messageId":"20060928173350.95443.qmail@web51004.mail.yahoo.com","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609281003070.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T17:33:50Z","receivedAt":"2006-09-28T17:33:50Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\n> Trust me. When we say that git ignores time, WE MEAN IT. Git does not rely \n> on time, git does not use time, git does not CARE!\n\nI understand that git doesn't care about time internally as it treats it as a random number for\npeople to care about or not on their own, I am only saying that local time is more likely to be\ncared about than disparate remote creation times. \n\nIt should be possible to export git data, through say a web interface, in a such a way that local\ntime order is consistent with commit order. \n\n-Matt\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27909","messageId":"Pine.LNX.4.63.0609281941570.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5710","inReplyTo":"20060928173350.95443.qmail@web51004.mail.yahoo.com","subject":"Re: git and time","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-28T17:42:12Z","receivedAt":"2006-09-28T17:42:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"On Thu, 28 Sep 2006, Matthew L Foster wrote:\n\n> It should be possible to export git data, through say a web interface, \n> in a such a way that local time order is consistent with commit order.\n\nWhy?\n"},{"id":"27911","messageId":"Pine.LNX.4.64.0609281043380.3952@g5.osdl.org","threadId":"5710","inReplyTo":"20060928173350.95443.qmail@web51004.mail.yahoo.com","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-28T18:01:55Z","receivedAt":"2006-09-28T18:01:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Sep 2006, Matthew L Foster wrote:\n> \n> It should be possible to export git data, through say a web interface, \n> in a such a way that local time order is consistent with commit order.\n\nI really don't think the thing you ask for exists.\n\nDon't get me wrong. You _can_ have a local time for each commit that \ntracks \"when did this commit show up in this particular branch\". Git \nalready supports that, even if gitweb cannot show it, and in fact showing \nit would be very hard (since the exact same commit can often exist in \nmultiple different branches, you'd have to show multiple times: in Junios \n\"git\" tree you often have a commit that showed up in the \"next\" branch \nthree weeks ago, but in the \"master\" branch only yesterday).\n\nThe _problem_ with this is that it makes the whole concept of time \nmeaningless. It's pointless. You can do it, but I guarantee you that once \nyou actually use it for a while, you'll want to go back. There are several \nreasons for that:\n\n - it means that the -same- exact project, when looked at frm two \n different sites that mirror it, have totally different times. In other \n words, the times have become pointless for something like gitweb.\n\n - it means that all times will be seriously \"compressed\", in that you'll \n find hundreds (or thousands) of commits that just have the same \n timestamp. You could try to \"spread them out\" by just making up some \n totally arbitrary mapping function, but that would basically have \n absolutely no basis in anything that has any relationship to \"reality\"\n\nSo it just doesn't make any sense.\n\nThe only thing that makes sense is that in your private repository (that \nis _not_ exported to others through \"gitweb\" or something like that), you \ncan ask yourself the question:\n\n\t\"What did my tree look like yesterday before I went out for a \n\t beer, and came back drunk as a toad, and screwed everything up?\"\n\nAnd the thing is, you can do that already. Just say\n\n\tgit log \"master@{18 hours ago}\"\n\nand git will hopefully show you (assuming you had enabled ref-logging as \ndescribed earlier in this thread) exactly what you wanted.\n\nSee? \n\nBut it does not make sense in _any_ other setting. Certainly not gitweb.\n\n\t\t\tLinus\n"},{"id":"27923","messageId":"20060928191816.76466.qmail@web51014.mail.yahoo.com","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609281043380.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T19:18:15Z","receivedAt":"2006-09-28T19:18:15Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Linus Torvalds wrote:\n \n> - it means that the -same- exact project, when looked at frm two \n> different sites that mirror it, have totally different times. In other \n> words, the times have become pointless for something like gitweb.\n\nMirrored git repos probably should use the same timestamp, e.g. the \"master\" or \"private\" git\nserver's local time. Replicated repos have a delay compared to when you made changes in your\nprivate repo, that is ok, replication is not what makes commit order inconsistent with time, it's\nthe act of pulling/merging from a server with misconfigured time and gitweb.cgi trusting \"creation\ntime\", right? Or is replication the same thing as merging/pulling? \n\n-Matt \n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27926","messageId":"20060928194316.42986.qmail@web51004.mail.yahoo.com","threadId":"5710","inReplyTo":"Pine.LNX.4.63.0609281941570.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T19:43:16Z","receivedAt":"2006-09-28T19:43:16Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Johannes Schindelin wrote:\n\n> On Thu, 28 Sep 2006, Matthew L Foster wrote:\n> \n> > It should be possible to export git data, through say a web interface, \n> > in a such a way that local time order is consistent with commit order.\n> \n> Why?\n\n- So exported data is never/rarely in an inconsistent state with respect to commit order and local\ntime order (data integrity).\n\n- To encourage people to care about/prefer local commit time rather than remote creation/emailed\ntime\n\n- So people that user repo X, or binaries from repo X, know when bug fix Y/fancy new feature Z was\ncommitted/merged locally\n\n- In many situations \"history\" is incomplete without local commit time. If a company has a new\ndriver they would probably prefer to know when the main kernel repo has it, not when they\ncreated/emailed it or when a remote repo committed it.\n\n-Matt\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27927","messageId":"20060928195056.GA3751@spearce.org","threadId":"5710","inReplyTo":"20060928194316.42986.qmail@web51004.mail.yahoo.com","subject":"Re: git and time","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-28T19:50:56Z","receivedAt":"2006-09-28T19:50:56Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Matthew L Foster wrote:\n> --- Johannes Schindelin wrote:\n> \n> > On Thu, 28 Sep 2006, Matthew L Foster wrote:\n> > \n> > > It should be possible to export git data, through say a web interface, \n> > > in a such a way that local time order is consistent with commit order.\n> > \n> > Why?\n> \n> - So exported data is never/rarely in an inconsistent state with respect to commit order and local\n> time order (data integrity).\n\nPick one. You can't have \"never\" and \"rarely\".\n \n> - To encourage people to care about/prefer local commit time rather than remote creation/emailed\n> time\n\nWhy? In general I don't care about time in Git. Maybe I care about\nwhen I authored something if my wife wants to know why I was up until\n6 am the night before (\"Look honey, I was coding until 6:00 am! See\nthe commit!\") but otherwise I don't find time to be that interesting.\n\nThen again I don't find time in the real world that intersting\neither. I'm either where I'm supposed to be or I'm not and I'll\nget there when I get there.\n\n> - So people that user repo X, or binaries from repo X, know when bug fix Y/fancy new feature Z was\n> committed/merged locally\n\nTrack it by version, not timestamp. Know what commit or tag SHA1\nwas used to produce that binary. Ask GIT if the fix is in that\nSHA1 ancestory or not. I've already said that on this thread.\n \n> - In many situations \"history\" is incomplete without local commit time. If a company has a new\n> driver they would probably prefer to know when the main kernel repo has it, not when they\n> created/emailed it or when a remote repo committed it.\n\nI think they care more about what release of the kernel will have\nthat driver. That can easily be determined by the DAG and by\nunderstanding what branch(es) will wind up in the next release and\ndoing simple math: \"Lets see, current release is version 2.6.9000,\nso it will be in 2.6.9001.\"\n\n-- \nShawn.\n"},{"id":"27931","messageId":"200609282236.37513.robin.rosenberg.lists@dewire.com","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609281003070.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-09-28T20:36:37Z","receivedAt":"2006-09-28T20:36:37Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"torsdag 28 september 2006 19:11 skrev Linus Torvalds:\n> The time that git records is purely a random number. It's a random number\n> that _humans_ can choose to care about or not, and it's a random number\n> that git itself uses only in the sense of \"ok, I've got two equal choices,\n> let's toss a coin to select which one I'll look at next\", BUT IT IS A\n> RANDOM NUMBER.\n\nI'd think of it as comment, about as (un)reliable as the author field or the \ndescriptive free-form comment people enter when they commit. It's not even \nnecessarily the local system time if GIT_AUTHOR_DATE has been set.\n\n-- robin\n"},{"id":"27932","messageId":"451C3494.8030701@gmail.com","threadId":"5710","inReplyTo":"20060928165509.77413.qmail@web51001.mail.yahoo.com","subject":"Re: git and time","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2006-09-28T20:46:12Z","receivedAt":"2006-09-28T20:46:12Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Matthew L Foster wrote:\n> --- Rogan Dawes wrote:\n> \n>> I just don't think that any of the kernel developers feel the need to \n>> police any one else's clocks . . . they're more interested in the \n>> contents of the patch.\n> \n> I am not saying git should \"police any one else's clocks\", I am saying git should be designed or\n> configured in such a way, using local time, that it obviates the current reliance on everyone\n> else's clock being set correctly. \n\nSounds like you're suggesting that Git should not record any timestamps \nat all. After all, Git doesn't need them.\n"},{"id":"27939","messageId":"20060928221237.85837.qmail@web51015.mail.yahoo.com","threadId":"5710","inReplyTo":"451C3494.8030701@gmail.com","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T22:12:37Z","receivedAt":"2006-09-28T22:12:37Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- A Large Angry SCM wrote:\n\n> Sounds like you're suggesting that Git should not record any timestamps \n> at all. After all, Git doesn't need them.\n\nYeah kind of, since distributed git doesn't need timestamps and can't guarantee them the only time\nthat might make any sense to use locally is local commit time. \n\n-Matt\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27942","messageId":"451C4BE6.20407@gmail.com","threadId":"5710","inReplyTo":"20060928221237.85837.qmail@web51015.mail.yahoo.com","subject":"Re: git and time","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2006-09-28T22:25:42Z","receivedAt":"2006-09-28T22:25:42Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Matthew L Foster wrote:\n> --- A Large Angry SCM wrote:\n> \n>> Sounds like you're suggesting that Git should not record any timestamps \n>> at all. After all, Git doesn't need them.\n> \n> Yeah kind of, since distributed git doesn't need timestamps and can't guarantee them the only time\n> that might make any sense to use locally is local commit time. \n\nThere is no local commit time for things you get from a remote repository.\n\nWhen I wrote \"Sounds like you're suggesting that Git should not record \nany timestamps at all\", I meant _you_ don't think Git should record \n_any_ timestamps since they can't be guaranteed to match the DAG.\n"},{"id":"27944","messageId":"20060928222935.66578.qmail@web51012.mail.yahoo.com","threadId":"5710","inReplyTo":"20060928195056.GA3751@spearce.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T22:29:35Z","receivedAt":"2006-09-28T22:29:35Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Shawn Pearce wrote:\n\n> > - So exported data is never/rarely in an inconsistent state with respect to commit order and\n> > local time order (data integrity).\n> \n> Pick one. You can't have \"never\" and \"rarely\".\n\nI mean \"rarely\" in the sense that there is no guarantee that local time is exact but any\ninexactness would be confined locally.\n \n> Track it by version, not timestamp. Know what commit or tag SHA1\n> was used to produce that binary. Ask GIT if the fix is in that\n> SHA1 ancestory or not. I've already said that on this thread.\n\nSo you are saying time, even local commit time, is completely unnecessary? I disagree. Git doesn't\nneed to keep track of any times in a distributed way, it just might be worthwhile to keep track of\nlocal commit timestamps internally per repo.\n\n> I think they care more about what release of the kernel will have\n> that driver. That can easily be determined by the DAG and by\n> understanding what branch(es) will wind up in the next release and\n> doing simple math: \"Lets see, current release is version 2.6.9000,\n> so it will be in 2.6.9001.\"\n\nEven if people care more about \"what release\" that doesn't mean they don't care about (local\ncommit) time.\n\n-Matt\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27945","messageId":"20060928223141.39864.qmail@web51010.mail.yahoo.com","threadId":"5710","inReplyTo":"451C4BE6.20407@gmail.com","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T22:31:41Z","receivedAt":"2006-09-28T22:31:41Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- A Large Angry SCM wrote:\n\n> There is no local commit time for things you get from a remote repository.\n\nAre you saying it's impossible to internally record/track local commit/merge time for things you\nget from a remote repository, ref-log?\n\n-Matt\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27946","messageId":"Pine.LNX.4.63.0609290032440.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5710","inReplyTo":"20060928222935.66578.qmail@web51012.mail.yahoo.com","subject":"Re: git and time","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-28T22:35:00Z","receivedAt":"2006-09-28T22:35:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Matt,\n\nwhat exactly are you trying to achieve here? Is this a sort of contest who \ncan have the longest thread on git@vger.kernel.org?\n\nIf you really want to understand why git does not rely on timestamps, and \nwhy it should not, and why you can still be happy nevertheless, there are \nenough answers in this thread.\n\nHth,\nDscho\n"},{"id":"27947","messageId":"20060928224551.8086.qmail@web51002.mail.yahoo.com","threadId":"5710","inReplyTo":"451C4BE6.20407@gmail.com","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T22:45:51Z","receivedAt":"2006-09-28T22:45:51Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- A Large Angry SCM wrote:\n\n> When I wrote \"Sounds like you're suggesting that Git should not record \n> any timestamps at all\", I meant _you_ don't think Git should record \n> _any_ timestamps since they can't be guaranteed to match the DAG.\n\nWell, I mean since there is no time order matching commit order guarantee for distributed git the\nonly timestamp to use for anything locally is local time (if timestamps are used at all). The\ncurrent remote creation or merge time could stay as is (I don't care either way), but at least\ngitweb.cgi should become local commit time/ref-log aware. Though if it's infeasible or requires\nsome rearchitecting it might not happen.\n\n-Matt \n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27948","messageId":"20060928225505.23517.qmail@web51003.mail.yahoo.com","threadId":"5710","inReplyTo":"Pine.LNX.4.63.0609290032440.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-28T22:55:05Z","receivedAt":"2006-09-28T22:55:05Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Johannes Schindelin wrote:\n\n> what exactly are you trying to achieve here? \n\nTimestamps not being all over the place in gitweb.cgi. \n\n> If you really want to understand why git does not rely on timestamps, and \n> why it should not, and why you can still be happy nevertheless, there are \n> enough answers in this thread.\n\nI agree and understand that distributed git should not and does not rely on timestamps, I am just\nsuggesting that it might be worthwhile to _locally_ track local commit time more efficiently for\nlocal use in things like gitweb.cgi. \n\n-Matt\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27963","messageId":"20060929002748.GA11055@thunk.org","threadId":"5710","inReplyTo":"20060928191816.76466.qmail@web51014.mail.yahoo.com","subject":"Re: git and time","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-09-29T00:27:48Z","receivedAt":"2006-09-29T00:27:48Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Sep 28, 2006 at 12:18:15PM -0700, Matthew L Foster wrote:\n> --- Linus Torvalds wrote:\n> \n> > - it means that the -same- exact project, when looked at frm two \n> > different sites that mirror it, have totally different times. In other \n> > words, the times have become pointless for something like gitweb.\n> \n> Mirrored git repos probably should use the same timestamp, e.g. the\n> \"master\" or \"private\" git server's local time. Replicated repos have\n> a delay compared to when you made changes in your private repo, that\n> is ok, replication is not what makes commit order inconsistent with\n> time, it's the act of pulling/merging from a server with\n> misconfigured time and gitweb.cgi trusting \"creation time\", right?\n> Or is replication the same thing as merging/pulling?\n\nGit mirroring takes place using the same pushing and pulling that are\nused with multiple repositories. That's why if Linus does a huge\namount of work over the period of a day or two in his private\nrepository, and then publishes it master.kernel.org, the \"local\" time\non master.kernel.org will be the time when they are pushed to\nmaster.kernel.org, because it's done via the same operation as any\nother repository push or pull.\n\nThat's what everyone has been trying to tell you for this entire\nthread....\n\n\t\t\t\t\t\t- Ted\n"},{"id":"27965","messageId":"20060929014430.44203.qmail@web51006.mail.yahoo.com","threadId":"5710","inReplyTo":"20060929002748.GA11055@thunk.org","subject":"Re: git and time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2006-09-29T01:44:30Z","receivedAt":"2006-09-29T01:44:30Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Theodore Tso wrote:\n\n> Git mirroring takes place using the same pushing and pulling that are\n> used with multiple repositories. That's why if Linus does a huge\n> amount of work over the period of a day or two in his private\n> repository, and then publishes it master.kernel.org, the \"local\" time\n> on master.kernel.org will be the time when they are pushed to\n> master.kernel.org, because it's done via the same operation as any\n> other repository push or pull.\n> \n> That's what everyone has been trying to tell you for this entire\n> thread....\n\nOk, I was wondering about that. In your example above the internally unnecessary timestamp will be\nfrom Linus' private repo, not master.kernel.org's? Even now knowing replication = merge/push/pull\nI still think it worthwile for local commit time to be effiently tracked locally and/or if already\navailable in the local ref-log used by things like gitweb.cgi if feasible but I might be the only\none that cares this much about time. Gitweb.cgi currently relies at least display/visually on\nthose internally unnecessary and potentially misleading timestamps...\n\n-Matt\n\n\n__________________________________________________\nDo You Yahoo!?\nTired of spam? Yahoo! Mail has the best spam protection around \nhttp://mail.yahoo.com \n"},{"id":"27966","messageId":"7virj7qudm.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"20060929014430.44203.qmail@web51006.mail.yahoo.com","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-29T02:28:05Z","receivedAt":"2006-09-29T02:28:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthew L Foster writes:\n\n> Ok, I was wondering about that. In your example above the\n> internally unnecessary timestamp will be from Linus' private\n> repo, not master.kernel.org's?\n\nYes, and it is stronger than that. If somebody did a sata\npatch, sent that to Jeff over e-mail, and if the patch was\naccepted, Jeff will make a commit in his private repository,\nrecording local time on his machine. Later Linus may pull from\nJeff and the commit object is transferred during that.\n\nTo Linus, the time he first saw the commit was the time he\npulled from Jeff, so being able to tell when it came into his\nrepository may help him if he pulled from other people too and\nthen suddenly realizes his sata disk does not respond at all.\n\nHe COULD say \"it was working yesterday, I pulled from Jeff 3\nhours ago, and then David 2 hours ago, I did not do my own\ndevelopment during that time. Did the breakage come when I\npulled from Jeff or when I pulled from David?\" ref-log would\nlet him do something like:\n\n\tgit checkout -b trythis master@{4.hours.ago}\n\nto make sure the state before he pulled from Jeff was a working\nstate and then still on the trythis branch he cuold do\n\n\tgit reset --hard master@{2.hours.30.minutes.ago}\n\nto see if the state after he pulled from Jeff was broken.\n\n\tSide note: in reality he does not have to care. He can\n\tjust bisect it without using any of his \"pull boundary\"\n\ttime.\n\nSo that was discussion about the time Linus first saw the\ncommit. What about us, general public? Until Linus pushes out\nthe merge result, we would not see it. Anyway, eventually he\nwill push his tip of the branch out to kernel.org and rsync will\nmirror to public git:// and gitweb machines.\n\nWhat's the local time the general public sees the commit for the\nfirst time? It's (forgetting for now the rsync mirroring delay)\nthe time Linus pushed the tip of the branch out. Along with all\nother hundreds of commits he acquired since the last time he\npushed his tree out.\n\nIt is sometimes useful to know when a particular commit has\nbecome available to the general public. I do not think anybody\nis denying it.\n\nBut it is a completely separate issue if it is useful to label\nthe commits that happened to be pushed out together at the same\ntime with the same timestamp on the gitweb short-log page (or\nshort-log corner on the summary page). Most of the time you\nwill see commits pushed out by the same push operation and\nhaving exactly the same timestamp. That's not very useful way\nto present the information.\n\n\tSide note: some commits arrive kernel.org machine\n\tearlier than others because Linus does not have infinite\n\tbandwidth to kernel.org, but these hundreds of commits\n\tbecome visible to the general public exactly the same\n\ttime, because we send them and as the last operation we\n\tupdate the tip of the branch. So you cannot even say\n\t\"record the time down to the second they arrived the\n\tkernel.org repository\" -- until the branch tip is\n\tupdated the general public cannot see them so the\n\tarrival time (mtime of .git/objects/??/???...?? files)\n\tdoes not even matter.\n\nIf somebody feels strongly about it, I would suggest adding that\ninformation on the commit page of gitweb, where the program\nneeds to deal with only one commit. That would help somebody\nwho is interested in _one_ particular commit and wants to know\nwhen it has become available to the general public.\n\n-\n"},{"id":"27985","messageId":"451CD0C2.2020805@op5.se","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609271918350.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-09-29T07:52:34Z","receivedAt":"2006-09-29T07:52:34Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> \n> On Wed, 27 Sep 2006, Matthew L Foster wrote:\n>> From a web display/generic notion of integrity perspective time order \n>> matters to me but it looks like I am the only one. Keeping track of \n>> _local_ commit time would not add any dependencies.\n> \n> Actually, I think one problem here is that anybody why looks at just the \n> gitweb interface may not realize how git works.\n> \n> If you use gitk as your primary way of learning about a git problem, the \n> whole time issue just goes away, because gitk shows the _real_ \n> relationships so well.\n> \n> I used gitk in all my initial explanations of git, because it turned a \n> fairly abstract \"here, let me explain how it works\" into a \"See? Look at \n> this\" kind of situation.\n> \n\nTrue that. I would have had a hard time introducing git as The SCM in \nthe company if it hadn't been for gitk and qgit. They both let you just \nskip over 90% of that initial steep part of the learning curve and jump \nstraight to work.\n\n> I think gitweb is great (in a way I have _never_ felt about any of the CVS \n> web interfaces I have ever seen), but gitweb doesn't really explain how \n> things work as well as gitk does.\n> \n\nSomeone started hacking on a web-thingie to show the graph. Whatever \nhappened to that? If it's no longer alive, perhaps we could add some \nqgit/gitk screenshots to the git wiki/docs so the people who spend most \nof their lives in browsers can get some visual aid in understanding the \nway git works.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"27987","messageId":"451CD663.8020806@op5.se","threadId":"5710","inReplyTo":"20060928194316.42986.qmail@web51004.mail.yahoo.com","subject":"Re: git and time","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-09-29T08:16:35Z","receivedAt":"2006-09-29T08:16:35Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthew L Foster wrote:\n> --- Johannes Schindelin wrote:\n> \n>> On Thu, 28 Sep 2006, Matthew L Foster wrote:\n>>\n>>> It should be possible to export git data, through say a web interface, \n>>> in a such a way that local time order is consistent with commit order.\n>> Why?\n> \n> - So exported data is never/rarely in an inconsistent state with respect to commit order and local\n> time order (data integrity).\n> \n\nMoot point (it has been iterated so many times that I can't be asked to \nrepeat it again).\n\n> - To encourage people to care about/prefer local commit time rather than remote creation/emailed\n> time\n> \n\nMost people use ntp, and are in general concerned with keeping their \nclocks in sync as lots of other software depend on it (calender \nfunctions, fe). It shouldn't be the task of project leaders to make sure \nthat the ~50000 random people around the world that submit patches to \nopensource projects every day all have their clocks in sync.\n\n> - So people that user repo X, or binaries from repo X, know when bug fix Y/fancy new feature Z was\n> committed/merged locally\n> \n\nCan be done using reflog. Feel free to submit patches. Make sure you \nsync your clock to whatever ntp-server or other timekeeping mechanism \nJunio uses before you commit and send your patch though. ;-)\n\n> - In many situations \"history\" is incomplete without local commit time. If a company has a new\n> driver they would probably prefer to know when the main kernel repo has it, not when they\n> created/emailed it or when a remote repo committed it.\n> \n\nSee the reflog response and, again, feel free to submit patches.\n\nTo get you started, I think the easiest way would be to teach gitweb \nabout the reflog, and then insert a line saying\n\"--- pushed to this repo $date ---\"\nor something like that in the summary page whenever a commit is found \nthat is also in the reflog. This should also be fairly CPU efficient if \nmy guesses on how gitweb and the reflog works are correct. CBA to check, \nsince I sincerely and whole-heartedly don't care about it myself.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"27994","messageId":"Pine.LNX.4.63.0609291605390.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5710","inReplyTo":"451CD0C2.2020805@op5.se","subject":"Re: git and time","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-29T14:09:03Z","receivedAt":"2006-09-29T14:09:03Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 29 Sep 2006, Andreas Ericsson wrote:\n\n> Someone started hacking on a web-thingie to show the graph. Whatever \n> happened to that?\n\nIt is called git-browser, and was done by Artem Khodush. See \nhttp://straytree.com/.\n\nI asked Artem what the plans are, since some features are not yet \nimplemented, but he said that the thing is too slow, and he'll probably \nnot continue to work on it.\n\nCiao,\nDscho\n"},{"id":"27995","messageId":"451D2BF7.10602@op5.se","threadId":"5710","inReplyTo":"Pine.LNX.4.63.0609291605390.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git and time","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-09-29T14:21:43Z","receivedAt":"2006-09-29T14:21:43Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Fri, 29 Sep 2006, Andreas Ericsson wrote:\n> \n>> Someone started hacking on a web-thingie to show the graph. Whatever \n>> happened to that?\n> \n> It is called git-browser, and was done by Artem Khodush. See \n> http://straytree.com/.\n> \n> I asked Artem what the plans are, since some features are not yet \n> implemented, but he said that the thing is too slow, and he'll probably \n> not continue to work on it.\n> \n\nAh well. I hope he keeps that page running though, and I hope the \n\"time-is-importan\" people find it.\n\nFor reference, it gives a crude (and indeed slow) picture of what gitk \nand qgit does.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"27999","messageId":"20060929173736.GA13635@delft.aura.cs.cmu.edu","threadId":"5710","inReplyTo":"20060926224133.714337eb.seanlkml@sympatico.ca","subject":"Re: git and time","fromName":"Jan Harkes","fromEmail":"jaharkes@cs.cmu.edu","sentAt":"2006-09-29T17:37:36Z","receivedAt":"2006-09-29T17:37:36Z","isPatch":false,"sender":{"key":"jaharkes@cs.cmu.edu","avatar":"https://gravatar.com/avatar/cf95aecd150ca8ef33d6edc337ac4bb9e13aa4246fc3679257d578c7fddc1633?d=mp&s=160"},"body":"On Tue, Sep 26, 2006 at 10:41:33PM -0400, Sean wrote:\n> It is interesting information for some people though. For instance\n> someone wondering how long ago Linus published a certain security fix.\n> To be able to say to easily query gitweb and be able to report,\n> \"Linus published that security fix X day ago etc..\"\n\nI don't see the point in knowing how many days ago the security fix was\npublished, since I'd really care if my machine is running a kernel that\ncontains the fix.\n\nSo I can see how I might want to know which branches (and/or tags) in my\nrepository contain the security fix. And this is pretty easy,\n\n#!/bin/sh\nfix=\"$(git-rev-parse --verify $1)\"\ngit ls-remote . | while read sha ref ; do\n [ \"$fix\" == \"$(git-merge-base \"$fix\" \"$sha\")\" ] && echo $ref\ndone\n\nOf course this could be cleaned up and extended quite a bit, possibly\nallowing a user to specify if he cares about only branches, or tags or\nsome specific branch.\n\nJan\n"},{"id":"28000","messageId":"BAYC1-PASMTP0367047EB7DF5A3C38BCABAE180@CEZ.ICE","threadId":"5710","inReplyTo":"20060929173736.GA13635@delft.aura.cs.cmu.edu","subject":"Re: git and time","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-09-29T17:46:16Z","receivedAt":"2006-09-29T17:46:16Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Fri, 29 Sep 2006 13:37:36 -0400\nJan Harkes wrote:\n\n> I don't see the point in knowing how many days ago the security fix was\n> published, since I'd really care if my machine is running a kernel that\n> contains the fix.\n\nIt was just a single example, one maybe not important to you. In fact\nit might be interesting to someone who isn't even running _any_ Linux\nkernel themselves; a security researcher or journalist for instance.\nThere are other examples as well. Maybe none of them would apply to\nyour needs, but there are people who would find it interesting and\nconvenient.\n\nSean\n"},{"id":"28012","messageId":"200609292242.05347.jnareb@gmail.com","threadId":"5710","inReplyTo":"20060927222854.82278.qmail@web51014.mail.yahoo.com","subject":"Re: git and time","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-29T20:42:05Z","receivedAt":"2006-09-29T20:42:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthew L. Foster wrote:\n> If the local merge time information is already available in the\n> ref-log then gitweb.cgi might only need to be made aware of it. \n\nIt is planned to add reflog support (view) to gitweb.\n\nBut of course the repository that is under gitweb has to have reflog \n_enabled_ to be able to view it.\n-- \nJakub Narebski\nPoland\n"},{"id":"28014","messageId":"200609292258.14294.jnareb@gmail.com","threadId":"5710","inReplyTo":"7vodt2nmft.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-29T20:58:14Z","receivedAt":"2006-09-29T20:58:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C. Hamano wrote:\n> I somehow thought that it was possible to get \"the latest tag\n> that precedes this commit\" (aka \"git describe\") for each commit\n> by visiting its commitdiff_plain page, but I do not see it now.\n> Can somebody tell me if I am hallucinating?\n\nNo, as of now \"commitdiff_plain\" or \"commit_plain\" view shows either \ngit-name-rev information, or just tag if the tag points exactly at \ngiven [child] commit, not git-describe information. Although it would \nbe fairly easy to add this information, though...\n-- \nJakub Narebski\nPoland\n"},{"id":"28017","messageId":"7vd59ejokp.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609281029300.9349@xanadu.home","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-29T22:27:34Z","receivedAt":"2006-09-29T22:27:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Wed, 27 Sep 2006, Junio C Hamano wrote:\n>\n>> Nicolas Pitre writes:\n>> \n>> > SYNOPSIS\n>> >\n>> > \tgit-local-arrival \n>> >\n>> > DESCRIPTION\n>> >\n>> > \tThe command displays the time when given commit appeared in the \n>> > \tlocal repository.\n>> \n>> This should be certainly doable, but local-arrival may not be\n>> interesting if the repository has more than one branches. Maybe\n>> \n>> \tgit-local-arrival []\n>> \n>> which defaults to the current branch?\n>\n> Indeed. I didn't mention it initially because it is really easy to do \n> once you have it working for the current branch. The technical \n> challenge is about making it efficient to find out which reflog entry \n> with a path to given commit is the oldest.\n\nThe more I think about this, if we were to add yet another\ncommand, I think it should be a command that lets us inspect\nref-log. We do not have an UI other than @{time} syntax to\ninteract with it right now.\n\nWhat are the things we would want? Here is a strawman.\n\n - List when and how a branch was changed.\n\n git ref-log --list --type=merge next (when did I merge into my 'next'?)\n git ref-log --list --type=merge (ditto but any branches)\n git ref-log --list next (any changes not just 'merge')\n\n I expect the output would give timestamp and reason comment;\n in addition the branch name when no branch is specified.\n Type does not have to be a concrete thing -- it could just be\n a substring match in the reason comment string.\n\n Also we would limit output with -n . The output\n should be sorted by the timestamp of ref-log entry -- we are\n talking about a particular repository's ref-log, so its\n timestamp has more sane meaning than in distributed case.\n \n - Find which branches currently contains a commit, and find the\n earliest time that the commit became part of each of them.\n\n git ref-log $commit next master (when did it enter 'next' and\n when did it graduate to 'master'?)\n git ref-log $commit (ditto but any branches)\n\n I expect the output to be the timestamp and reason comment;\n in addition the branch name when no branch is specified.\n\nAlso for a shared repository, the person who made the change\nwould be a reasonable thing to report.\n\nSo for consistency, in all cases we could make the output\nformat like this:\n\n branch SP time-and-zone SP name SP email SP reason-comment LF\n\nwhere time-and-zone is human-readable timestamp as we see in\ngit-log output.\n"},{"id":"28022","messageId":"20060930045037.GB18479@spearce.org","threadId":"5710","inReplyTo":"7vd59ejokp.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-09-30T04:50:37Z","receivedAt":"2006-09-30T04:50:37Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> The more I think about this, if we were to add yet another\n> command, I think it should be a command that lets us inspect\n> ref-log. We do not have an UI other than @{time} syntax to\n> interact with it right now.\n\nAgreed. I've been missing such a command and have wanted to add\none but it wasn't important enough to me to actually code it. :)\n \n> What are the things we would want? Here is a strawman.\n> \n> - List when and how a branch was changed.\n> \n> git ref-log --list --type=merge next (when did I merge into my 'next'?)\n> git ref-log --list --type=merge (ditto but any branches)\n> git ref-log --list next (any changes not just 'merge')\n> \n> I expect the output would give timestamp and reason comment;\n> in addition the branch name when no branch is specified.\n> Type does not have to be a concrete thing -- it could just be\n> a substring match in the reason comment string.\n\nWhat about --grep=pat instead of --type?\n\nYou are talking about essentially the same behavior as\n`git log --grep=pat` except applying it to the message\nin the reflog rather than to message in the commits.\n\nAlso I think that this should be the default behavior\nand thus --list shouldn't be an option. This matches\ngit-log's default behavior to just show whatever is\nin the named branches.\n\n> Also we would limit output with -n .\n\nI'd limit with \"--max-count=\" like we do with git-log.\n\n> The output\n> should be sorted by the timestamp of ref-log entry -- we are\n> talking about a particular repository's ref-log, so its\n> timestamp has more sane meaning than in distributed case.\n\nAgreed, sorting newest -> oldest so newest displays first, much as\ngit-log does. This way its order of operation, much as git-log is\norder of operation.\n\nIf multiple branches are specified we really should interleave the\nvarious reflogs according to timestamps, to show the \"global picture\"\nof what happened in this repository.\n\n> - Find which branches currently contains a commit, and find the\n> earliest time that the commit became part of each of them.\n> \n> git ref-log $commit next master (when did it enter 'next' and\n> when did it graduate to 'master'?)\n> git ref-log $commit (ditto but any branches)\n\nSince I'm suggesting above that this behavior not be the default\nwhat about:\n\n git ref-log --arrive=$commit next master\n git ref-log --arrive=$commit\n?\n\n> I expect the output to be the timestamp and reason comment;\n> in addition the branch name when no branch is specified.\n\nAgreed.\n\n> Also for a shared repository, the person who made the change\n> would be a reasonable thing to report.\n\nI think that should be shown no matter what; even if\ncore.sharedRepository is false.\n\n> So for consistency, in all cases we could make the output\n> format like this:\n> \n> branch SP time-and-zone SP name SP email SP reason-comment LF\n\nThat's too long of a line with most reason-comments in the ref-log.\nEspecially ones that come from git-commit, and especially if they\nwere human written commit messages.\n\nI'd like to see the output be more like git-log. Allow a --pretty\noption with a few useful formats:\n\n --pretty=full:\n branch branchname LF\n from old\n to new\n Modifier: name SP email\n Date: time-and-zone\n\n reason-comment\n\n --pretty=oneline:\n branchname SP time-and-zone SP name SP email SP reason-comment LF\n\n --pretty=raw is obviously the exact line in the reflog but with\n the branch name preceeding it if more than one branch was specified\n or none were specified.\n\nAnd --pretty=full should be the default, much as --pretty=medium\nis with git-log.\n\n-- \nShawn.\n"},{"id":"28025","messageId":"7v4pupizix.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"20060930045037.GB18479@spearce.org","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-30T07:28:38Z","receivedAt":"2006-09-30T07:28:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Agreed. I've been missing such a command and have wanted to add\n> one but it wasn't important enough to me to actually code it. :)\n\nEverything you said in your message sounds sane and makes sense\nto me. Now we have to find a sucker^Wvolunteer to implement it\n;-).\n"},{"id":"28029","messageId":"Pine.LNX.4.64.0609301033460.3952@g5.osdl.org","threadId":"5710","inReplyTo":"7v4pupizix.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-30T17:36:26Z","receivedAt":"2006-09-30T17:36:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 30 Sep 2006, Junio C Hamano wrote:\n\n> Shawn Pearce writes:\n> \n> > Agreed. I've been missing such a command and have wanted to add\n> > one but it wasn't important enough to me to actually code it. :)\n> \n> Everything you said in your message sounds sane and makes sense\n> to me. Now we have to find a sucker^Wvolunteer to implement it\n> ;-).\n\nEhh. As far as I can see it's \n - a damn hard thing to do efficiently\n - essentially exactly the same problem you already solved with \"git \n describe\"\n\nIn other words, I think you could make git describe do it, by simply \nmaking it parse not just all tags, but also walking the branch log.\n\n\t\tLinus\n"},{"id":"28047","messageId":"7vd59d7y8v.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609301033460.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-30T23:04:00Z","receivedAt":"2006-09-30T23:04:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sat, 30 Sep 2006, Junio C Hamano wrote:\n>\n>> Shawn Pearce writes:\n>> \n>> > Agreed. I've been missing such a command and have wanted to add\n>> > one but it wasn't important enough to me to actually code it. :)\n>> \n>> Everything you said in your message sounds sane and makes sense\n>> to me. Now we have to find a sucker^Wvolunteer to implement it\n>> ;-).\n>\n> Ehh. As far as I can see it's \n> - a damn hard thing to do efficiently\n> - essentially exactly the same problem you already solved with \"git \n> describe\"\n>\n> In other words, I think you could make git describe do it, by simply \n> making it parse not just all tags, but also walking the branch log.\n\nAs a user interface, I think it makes a lot of sense to have\n\"git describe\" do it without introducing a new command.\n\nHowever, I think the traditional \"find the closest ancestor\"\nbehaviour and ref-log behaviour are mutually incompatible, while\nthey both return information to help address similar issues to\nthe end user when viewed at a very high level.\n\nEspecially, \"find the closest ancestor\" behaviour means when you\nget \"tag-gXXXX\" as an answer, the tag proper does _not_ contain\nthe given commit (e.g. commit v1.4.2-g4839bd8 is not part of\nv1.4.2). To answer \"when did the fix deadbeef go into master\nbranch\", reporting \"master@{yesterday}-gdeadbeef\" with the same\nlogic and format is misleading; \"master@{yesterday}\" may be the\nclosest ancestor of commit deadbeef, but that means it does\n_not_ contain the fix. When walking ref-log, we want it the\nother way around: \"find the earliest descendant among the\nentries in ref-log for a particular branch\".\n\nThe internal logic for doing that may be somewhat different and\nI suspect you may not be able to share much code with the\nexisting logic..\n"},{"id":"28048","messageId":"Pine.LNX.4.64.0609301712340.3952@g5.osdl.org","threadId":"5710","inReplyTo":"7vd59d7y8v.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-01T00:13:15Z","receivedAt":"2006-10-01T00:13:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 30 Sep 2006, Junio C Hamano wrote:\n> \n> However, I think the traditional \"find the closest ancestor\"\n> behaviour and ref-log behaviour are mutually incompatible, while\n> they both return information to help address similar issues to\n> the end user when viewed at a very high level.\n> \n> Especially, \"find the closest ancestor\" behaviour means when you\n> get \"tag-gXXXX\" as an answer, the tag proper does _not_ contain\n> the given commit (e.g. commit v1.4.2-g4839bd8 is not part of\n> v1.4.2).\n\nCorrect.\n\nBut that just means that we should take the _next_ one in the time-ordered \nlist, no?\n\n\t\tLinus\n"},{"id":"28050","messageId":"7v64f47uix.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609301712340.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-01T00:24:22Z","receivedAt":"2006-10-01T00:24:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sat, 30 Sep 2006, Junio C Hamano wrote:\n>> \n>> However, I think the traditional \"find the closest ancestor\"\n>> behaviour and ref-log behaviour are mutually incompatible, while\n>> they both return information to help address similar issues to\n>> the end user when viewed at a very high level.\n>> \n>> Especially, \"find the closest ancestor\" behaviour means when you\n>> get \"tag-gXXXX\" as an answer, the tag proper does _not_ contain\n>> the given commit (e.g. commit v1.4.2-g4839bd8 is not part of\n>> v1.4.2).\n>\n> Correct.\n>\n> But that just means that we should take the _next_ one in the time-ordered \n> list, no?\n\nI do not think so.\n\nExtending the example (sorry for doing the same topic on two\nseparate threads) I just gave Jeff on \"fix based on v0.99\",\nafter finding that the fix is based on v0.99, finding another\ncommit that immediately followed the v0.99 commit on my master\nbranch does not help finding out that I very recently merged the\nfix in at all. I think we cannot get away without honestly\ndoing the first descendant, which is unfortunately a lot more\nexpensive.\n"},{"id":"28055","messageId":"7vbqow5uht.fsf@assigned-by-dhcp.cox.net","threadId":"5710","inReplyTo":"7v64f47uix.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-01T08:07:58Z","receivedAt":"2006-10-01T08:07:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Linus Torvalds writes:\n>\n>> On Sat, 30 Sep 2006, Junio C Hamano wrote:\n>>> \n>>> Especially, \"find the closest ancestor\" behaviour means when you\n>>> get \"tag-gXXXX\" as an answer, the tag proper does _not_ contain\n>>> the given commit (e.g. commit v1.4.2-g4839bd8 is not part of\n>>> v1.4.2).\n>>\n>> Correct.\n>>\n>> But that just means that we should take the _next_ one in the time-ordered \n>> list, no?\n>\n> I do not think so.\n>\n> Extending the example (sorry for doing the same topic on two\n> separate threads) I just gave Jeff on \"fix based on v0.99\",\n> after finding that the fix is based on v0.99, finding another\n> commit that immediately followed the v0.99 commit on my master\n> branch does not help finding out that I very recently merged the\n> fix in at all. I think we cannot get away without honestly\n> doing the first descendant, which is unfortunately a lot more\n> expensive.\n\nMaybe not *that* expensive. Here is an outline, thinking aloud.\n\nWhen describing a commit and a ref, we first run the ancestry\ntraversal algorithm merge-base uses internally. If the tip of\nthe ref is not a descendant of the commit, abort (I'll justify\nthis in a moment).\n\nOtherwise, we would already have parsed all the necessary\ncommits we need to determine which commits on the given ref's\nancestry is the first one that is a descendant of the target\ncommit at this point. We collect these commits in a set, and\nthen mark the ones that are immediate children of the target\ncommit, then the ones that are children of them, etc. until we\nfind all the descendant of the target commit.\n\nAfter that, we can bisect the reflog for the ref to find the\nfirst commit that we have marked as a descendant of the target\ncommit in the above process.\n\nIf the tip of the ref is not a descendant of the commit to begin\nwith, that does not automatically mean that the target commit\nhas never been part of the ref -- the ref _could_ have contained\nit and then later got rewound. But then the question \"when did\nthe commit has become part of this branch\" itself stops being\ninteresting. It would not do us much good if we know it was\npart of the branch for only two days last week but it is not\ncontained in the branch anymore.\n"},{"id":"28056","messageId":"Pine.LNX.4.63.0610011034550.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5710","inReplyTo":"7v64f47uix.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-01T08:37:09Z","receivedAt":"2006-10-01T08:37:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 30 Sep 2006, Junio C Hamano wrote:\n\n> I think we cannot get away without honestly doing the first descendant, \n> which is unfortunately a lot more expensive.\n\n... and which happens to be almost implemented in git-name-rev.\n\nCiao,\nDscho\n"},{"id":"28123","messageId":"efs8js$gt7$1@sea.gmane.org","threadId":"5710","inReplyTo":"7vd59d7y8v.fsf@assigned-by-dhcp.cox.net","subject":"Re: git and time","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-02T23:50:47Z","receivedAt":"2006-10-02T23:50:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n>> On Sat, 30 Sep 2006, Junio C Hamano wrote:\n>>\n>>> Shawn Pearce writes:\n>>> \n>>> > Agreed. I've been missing such a command and have wanted to add\n>>> > one but it wasn't important enough to me to actually code it. :)\n>>> \n>>> Everything you said in your message sounds sane and makes sense\n>>> to me. Now we have to find a sucker^Wvolunteer to implement it\n>>> ;-).\n>>\n>> Ehh. As far as I can see it's \n>> - a damn hard thing to do efficiently\n>> - essentially exactly the same problem you already solved with \"git \n>> describe\"\n>>\n>> In other words, I think you could make git describe do it, by simply \n>> making it parse not just all tags, but also walking the branch log.\n> \n> As a user interface, I think it makes a lot of sense to have\n> \"git describe\" do it without introducing a new command.\n> \n> However, I think the traditional \"find the closest ancestor\"\n> behaviour and ref-log behaviour are mutually incompatible, while\n> they both return information to help address similar issues to\n> the end user when viewed at a very high level.\n> \n> Especially, \"find the closest ancestor\" behaviour means when you\n> get \"tag-gXXXX\" as an answer, the tag proper does _not_ contain\n> the given commit (e.g. commit v1.4.2-g4839bd8 is not part of\n> v1.4.2). To answer \"when did the fix deadbeef go into master\n> branch\", reporting \"master@{yesterday}-gdeadbeef\" with the same\n> logic and format is misleading; \"master@{yesterday}\" may be the\n> closest ancestor of commit deadbeef, but that means it does\n> _not_ contain the fix. When walking ref-log, we want it the\n> other way around: \"find the earliest descendant among the\n> entries in ref-log for a particular branch\".\n> \n> The internal logic for doing that may be somewhat different and\n> I suspect you may not be able to share much code with the\n> existing logic..\n\nIsn't git-name-rev doing kind of earliest descendant among refs?\nWell, I'm not sure if name-rev does not use shortest description\ninstead of earliest (closest) descendant... but we could extend it.\nI'd like also to limit refs used to given pattern, and perhaps\nalso to only tag objects.\n\nThis is command to extend it using it together with ref-log to know\nwhen given fix appeared in repository.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28124","messageId":"efs97p$jnd$1@sea.gmane.org","threadId":"5710","inReplyTo":"Pine.LNX.4.64.0609261849430.3952@g5.osdl.org","subject":"Re: git and time","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-03T00:01:23Z","receivedAt":"2006-10-03T00:01:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> Now, in some sense, you can ignore the difference between the two models, \n> since you'd think that they are totally equivalent: from the git model, \n> you can always get the \"changeset\" by just diffing the current state with \n> the previous state, and conversely from the \"changeset\" model you can \n> always get the \"current state\" by just applying the changeset to the \n> previous state.\n\nAnd if I understand correctly, that is how StGit and pg (Patchy Git), which\nare patch management applications similar in the purpose to the Quilt, and\nare based on Git, works.\n\nhttp://wiki.procode.org/cgi-bin/wiki.cgi/StGITtheory\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}