{"thread":{"id":"32214","subject":"Millisecond precision in timestamps?","startedAt":"2012-11-27T20:48:28Z","lastAt":"2012-12-10T20:56:19Z","messageCount":41,"participants":["Eric S. Raymond","Shawn Pearce","Pyeron, Jason J CTR (US)","Junio C Hamano","David Lang","Felipe Contreras","Jeff King","Jason Pyeron","David Aguilar","Thomas Berg","Andreas Ericsson","Phil Hord","Robin Rosenberg","James Cloos"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"204025","messageId":"20121127204828.577264065F@snark.thyrsus.com","threadId":"32214","inReplyTo":null,"subject":"Millisecond precision in timestamps?","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-27T20:48:28Z","receivedAt":"2012-11-27T20:48:28Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Because I do a lot of work on repository conversion tools, I've had\nto learn a lot of detail about ontological mismatches between\nversion-control systems - especially places where you lose metadata\nmoving between them.\n\nIn general, git metadata can carry forward almost all the metadata in\na Subversion repository.  Among the handful of minor exceptions (empty\ndirectories, flow structure, certain kinds of mergeinfos) there is one\nthat stands out because it seems to be an implementation detail rather\nthan a consequence of fundamentally different design decisions.\n\nI refer to the one-second precision of git timestamps.  Subversion\nstores its commit and property-change timestamps to microsecond\nprecision; conversion tools have to throw the subsecond part of\nthis information away.\n\nHas going to timestamps with the full precision of the system clock\nbeen considered and rejected, or am I the first to bring this up?\n\nIf I were to write refactoring patches that treated \"timestamp\" as\nan ADT, with a view towards hiding the difference between int and\nfloat timestamps and eventually experimenting with float ones, \nwould they be accepted?\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n\nEvery Communist must grasp the truth, 'Political power grows out of\nthe barrel of a gun.'\n        -- Mao Tse-tung, 1938, inadvertently endorsing the Second Amendment.\n"},{"id":"204036","messageId":"CAJo=hJtZ+n+D4pOmeNApDeLNyZYeqnEDDYJWwSj_wLauQ+w4hQ@mail.gmail.com","threadId":"32214","inReplyTo":"20121127204828.577264065F@snark.thyrsus.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2012-11-27T21:41:32Z","receivedAt":"2012-11-27T21:41:32Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Tue, Nov 27, 2012 at 12:48 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Because I do a lot of work on repository conversion tools, I've had\n> to learn a lot of detail about ontological mismatches between\n> version-control systems - especially places where you lose metadata\n> moving between them.\n>\n> In general, git metadata can carry forward almost all the metadata in\n> a Subversion repository.  Among the handful of minor exceptions (empty\n> directories, flow structure, certain kinds of mergeinfos) there is one\n> that stands out because it seems to be an implementation detail rather\n> than a consequence of fundamentally different design decisions.\n>\n> I refer to the one-second precision of git timestamps.  Subversion\n> stores its commit and property-change timestamps to microsecond\n> precision; conversion tools have to throw the subsecond part of\n> this information away.\n>\n> Has going to timestamps with the full precision of the system clock\n> been considered and rejected, or am I the first to bring this up?\n>\n> If I were to write refactoring patches that treated \"timestamp\" as\n> an ADT, with a view towards hiding the difference between int and\n> float timestamps and eventually experimenting with float ones,\n> would they be accepted?\n\nJGit would fortunately ignore a floating point timestamp specification\nif given in a commit, but I don't know about other Git\nimplementations... like say git. :-)\n"},{"id":"204037","messageId":"871B6C10EBEFE342A772D1159D13208537AC601E@umechphg.easf.csd.disa.mil","threadId":"32214","inReplyTo":"20121127204828.577264065F@snark.thyrsus.com","subject":"RE: Millisecond precision in timestamps?","fromName":"Pyeron, Jason J CTR (US)","fromEmail":"jason.j.pyeron.ctr@mail.mil","sentAt":"2012-11-27T21:44:34Z","receivedAt":"2012-11-27T21:44:34Z","isPatch":false,"sender":{"key":"jason.j.pyeron.ctr@mail.mil","avatar":null},"body":"> -----Original Message-----\n> From: Eric S. Raymond\n> Sent: Tuesday, November 27, 2012 3:48 PM\n> \n> Because I do a lot of work on repository conversion tools, I've had\n> to learn a lot of detail about ontological mismatches between\n> version-control systems - especially places where you lose metadata\n> moving between them.\n> \n> In general, git metadata can carry forward almost all the metadata in\n> a Subversion repository.  Among the handful of minor exceptions (empty\n> directories, flow structure, certain kinds of mergeinfos) there is one\n> that stands out because it seems to be an implementation detail rather\n> than a consequence of fundamentally different design decisions.\n> \n> I refer to the one-second precision of git timestamps.  Subversion\n> stores its commit and property-change timestamps to microsecond\n> precision; conversion tools have to throw the subsecond part of\n> this information away.\n> \n> Has going to timestamps with the full precision of the system clock\n> been considered and rejected, or am I the first to bring this up?\n> \n> If I were to write refactoring patches that treated \"timestamp\" as\n> an ADT, with a view towards hiding the difference between int and\n> float timestamps and eventually experimenting with float ones,\n\nDo you really mean floating point numbers with approximate imprecise values?\n\n\n"},{"id":"204040","messageId":"7vzk22lmz9.fsf@alter.siamese.dyndns.org","threadId":"32214","inReplyTo":"CAJo=hJtZ+n+D4pOmeNApDeLNyZYeqnEDDYJWwSj_wLauQ+w4hQ@mail.gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-27T22:06:34Z","receivedAt":"2012-11-27T22:06:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> JGit would fortunately ignore a floating point timestamp specification\n> if given in a commit, but I don't know about other Git\n> implementations... like say git. :-)\n\nfsck_ident() in fsck.c rejects anything but \" [1-9][0-9]* \" after\nthe author and committer ident (i.e. the timestamp has to be\nintegral number of seconds since the epoch, not before it, nor\nwith fractional seconds).\n"},{"id":"204050","messageId":"20121127230419.GA26080@thyrsus.com","threadId":"32214","inReplyTo":"7vzk22lmz9.fsf@alter.siamese.dyndns.org","subject":"Re: Millisecond precision in timestamps?","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-27T23:04:19Z","receivedAt":"2012-11-27T23:04:19Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Junio C Hamano <gitster@pobox.com>:\n> fsck_ident() in fsck.c rejects anything but \" [1-9][0-9]* \" after\n> the author and committer ident (i.e. the timestamp has to be\n> integral number of seconds since the epoch, not before it, nor\n> with fractional seconds).\n\nIs this architecturally significant?  It sounds like another\nimplementation detail.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204063","messageId":"CAJo=hJtOqRHcjWH1F71Qc5zvPkUAe+u1RrcC2pt_xQwLSUY0yg@mail.gmail.com","threadId":"32214","inReplyTo":"20121127230419.GA26080@thyrsus.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2012-11-27T23:49:18Z","receivedAt":"2012-11-27T23:49:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Tue, Nov 27, 2012 at 3:04 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Junio C Hamano <gitster@pobox.com>:\n>> fsck_ident() in fsck.c rejects anything but \" [1-9][0-9]* \" after\n>> the author and committer ident (i.e. the timestamp has to be\n>> integral number of seconds since the epoch, not before it, nor\n>> with fractional seconds).\n>\n> Is this architecturally significant?  It sounds like another\n> implementation detail.\n\nWell... if we added a fractional seconds to a commit, older versions\nof Git will scream loudly and refuse to work with the new commit. That\nwould create a fork of Git.\n"},{"id":"204067","messageId":"20121128001231.GA27971@thyrsus.com","threadId":"32214","inReplyTo":"CAJo=hJtOqRHcjWH1F71Qc5zvPkUAe+u1RrcC2pt_xQwLSUY0yg@mail.gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-28T00:12:32Z","receivedAt":"2012-11-28T00:12:32Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Shawn Pearce <spearce@spearce.org>:\n> Well... if we added a fractional seconds to a commit, older versions\n> of Git will scream loudly and refuse to work with the new commit. That\n> would create a fork of Git.\n\nSo much for that idea, I guess.  \n\nUnless..I don't know how git's database representations work.  Are they\nversion-stamped in any way?  If so, some slightly painful hackery would\nget around that problem.\n\nI'm being exploratory, here. No proposal to code anything is in the\noffing.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204071","messageId":"alpine.DEB.2.02.1211271620220.16794@nftneq.ynat.uz","threadId":"32214","inReplyTo":"20121128001231.GA27971@thyrsus.com","subject":"Re: Millisecond precision in timestamps?","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2012-11-28T00:22:57Z","receivedAt":"2012-11-28T00:22:57Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Tue, 27 Nov 2012, Eric S. Raymond wrote:\n\n> Shawn Pearce <spearce@spearce.org>:\n>> Well... if we added a fractional seconds to a commit, older versions\n>> of Git will scream loudly and refuse to work with the new commit. That\n>> would create a fork of Git.\n>\n> So much for that idea, I guess.\n>\n> Unless..I don't know how git's database representations work.  Are they\n> version-stamped in any way?  If so, some slightly painful hackery would\n> get around that problem.\n>\n> I'm being exploratory, here. No proposal to code anything is in the\n> offing.\n\nApologies if this was covered earlier in the thread (I missed the beginning)\n\nremember that git is dealing with timestamps generated across different \nmachines, and since the times are not assumed to be in sync, let alone to the \nmillisecond level, there's not much value to git in that level of presision.\n\ngit routinely deals with timestamps that are off by days. If the timestamps are \nwithin a minute or so, you are in pretty good shape.\n\nDavid Lang\n"},{"id":"204072","messageId":"CAMP44s3hpuxbo7mfKAD2trOkezPrV3nKYpNAzXOs3sQym102LQ@mail.gmail.com","threadId":"32214","inReplyTo":"20121128001231.GA27971@thyrsus.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-28T00:26:22Z","receivedAt":"2012-11-28T00:26:22Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Shawn Pearce <spearce@spearce.org>:\n>> Well... if we added a fractional seconds to a commit, older versions\n>> of Git will scream loudly and refuse to work with the new commit. That\n>> would create a fork of Git.\n>\n> So much for that idea, I guess.\n>\n> Unless..I don't know how git's database representations work.  Are they\n> version-stamped in any way?  If so, some slightly painful hackery would\n> get around that problem.\n\n% git cat-file -p HEAD\n\nYou'll see exactly how git stores commits. Changing anything in there\nmust be done carefully.\n\n-- \nFelipe Contreras\n"},{"id":"204082","messageId":"CAJo=hJuskvYaNTtCcTSqvU8YwEU=HwRpb_sqW-BSxfSr7xE57A@mail.gmail.com","threadId":"32214","inReplyTo":"CAMP44s3hpuxbo7mfKAD2trOkezPrV3nKYpNAzXOs3sQym102LQ@mail.gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2012-11-28T01:07:34Z","receivedAt":"2012-11-28T01:07:34Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n> On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n>> Shawn Pearce <spearce@spearce.org>:\n>>> Well... if we added a fractional seconds to a commit, older versions\n>>> of Git will scream loudly and refuse to work with the new commit. That\n>>> would create a fork of Git.\n>>\n>> So much for that idea, I guess.\n>>\n>> Unless..I don't know how git's database representations work.  Are they\n>> version-stamped in any way?  If so, some slightly painful hackery would\n>> get around that problem.\n>\n> % git cat-file -p HEAD\n>\n> You'll see exactly how git stores commits. Changing anything in there\n> must be done carefully.\n\nApparently there is no room to change in these fields without breaking\ncompatibility with all current versions of Git. So its not just done\ncarefully... its deciding to make Git 2.0 that is not compatible with\nany Git 1.x release.\n"},{"id":"204083","messageId":"20121128011136.GA29674@thyrsus.com","threadId":"32214","inReplyTo":"CAMP44s3hpuxbo7mfKAD2trOkezPrV3nKYpNAzXOs3sQym102LQ@mail.gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-28T01:11:36Z","receivedAt":"2012-11-28T01:11:36Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com>:\n> % git cat-file -p HEAD\n> \n> You'll see exactly how git stores commits. Changing anything in there\n> must be done carefully.\n\nOh, I've seen *that* before.  Are you telling me the database \nrepresentation is actually textual?\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204084","messageId":"20121128011750.GA23498@sigill.intra.peff.net","threadId":"32214","inReplyTo":"CAJo=hJuskvYaNTtCcTSqvU8YwEU=HwRpb_sqW-BSxfSr7xE57A@mail.gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-28T01:17:50Z","receivedAt":"2012-11-28T01:17:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 27, 2012 at 05:07:34PM -0800, Shawn O. Pearce wrote:\n\n> On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras\n> <felipe.contreras@gmail.com> wrote:\n> > On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> >> Shawn Pearce <spearce@spearce.org>:\n> >>> Well... if we added a fractional seconds to a commit, older versions\n> >>> of Git will scream loudly and refuse to work with the new commit. That\n> >>> would create a fork of Git.\n> >>\n> >> So much for that idea, I guess.\n> >>\n> >> Unless..I don't know how git's database representations work.  Are they\n> >> version-stamped in any way?  If so, some slightly painful hackery would\n> >> get around that problem.\n> >\n> > % git cat-file -p HEAD\n> >\n> > You'll see exactly how git stores commits. Changing anything in there\n> > must be done carefully.\n> \n> Apparently there is no room to change in these fields without breaking\n> compatibility with all current versions of Git. So its not just done\n> carefully... its deciding to make Git 2.0 that is not compatible with\n> any Git 1.x release.\n\nThere is room for new headers, and older versions of git will ignore\nthem. You could add a new \"committer-timestamp\" field that elaborates on\nthe timestamp included on the committer line. Newer versions of git\nwould respect it, and older versions would fall back to using the\ncommitter timestamp.\n\nBut I really wonder if anybody actually cares about adding sub-second\ntimestamp support, or if it is merely \"because SVN has it\".\n\n-Peff\n"},{"id":"204086","messageId":"EE15DF282E7C4196A32EE0818A64E35D@black","threadId":"32214","inReplyTo":"20121128011750.GA23498@sigill.intra.peff.net","subject":"RE: Millisecond precision in timestamps?","fromName":"Jason Pyeron","fromEmail":"jpyeron@pdinc.us","sentAt":"2012-11-28T01:29:45Z","receivedAt":"2012-11-28T01:29:45Z","isPatch":false,"sender":{"key":"jpyeron@pdinc.us","avatar":"https://gravatar.com/avatar/c2e53452caa53d940768a1ffc9cf76196d851b9b534b7a39cd39852a70a0508f?d=mp&s=160"},"body":"> -----Original Message-----\n> From: Jeff King\n> Sent: Tuesday, November 27, 2012 20:18\n> \n> On Tue, Nov 27, 2012 at 05:07:34PM -0800, Shawn O. Pearce wrote:\n> \n> > On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras \n> > <felipe.contreras@gmail.com> wrote:\n> > > On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond \n> <esr@thyrsus.com> wrote:\n> > >> Shawn Pearce <spearce@spearce.org>:\n> > >>> Well... if we added a fractional seconds to a commit, older \n> > >>> versions of Git will scream loudly and refuse to work \n> with the new \n> > >>> commit. That would create a fork of Git.\n> > >>\n> > >> So much for that idea, I guess.\n> > >>\n> > >> Unless..I don't know how git's database representations \n> work.  Are \n> > >> they version-stamped in any way?  If so, some slightly painful \n> > >> hackery would get around that problem.\n> > >\n> > > % git cat-file -p HEAD\n> > >\n> > > You'll see exactly how git stores commits. Changing anything in \n> > > there must be done carefully.\n> > \n> > Apparently there is no room to change in these fields \n> without breaking \n> > compatibility with all current versions of Git. So its not \n> just done \n> > carefully... its deciding to make Git 2.0 that is not \n> compatible with \n> > any Git 1.x release.\n> \n> There is room for new headers, and older versions of git will \n> ignore them. You could add a new \"committer-timestamp\" field \n> that elaborates on the timestamp included on the committer \n> line. Newer versions of git would respect it, and older \n> versions would fall back to using the committer timestamp.\n\nSuggestion add a ms offset field. Ex:\n\njpyeron@black /projects/git/git\n$ git cat-file -p HEAD\ntree 1e24acfbfcc05aa57e8cb2cfe3ffe01cb100961d\nparent e98fa647aa5673cc95b6e9be1fdc13c0afa2cb37\nauthor Junio C Hamano <gitster@pobox.com> 1350495361 -0700\ncommitter Junio C Hamano <gitster@pobox.com> 1350495402 -0700\nmstimestamps author 0 committer 1234\n\nGit 1.7.12.4\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n\n\n> \n> But I really wonder if anybody actually cares about adding \n> sub-second timestamp support, or if it is merely \"because SVN has it\".\n\nNot because subversion has it but because date != git(precisedate) and some\nautomation using git in a larger enterprise workflow may assume that date\n1354065991.1234 going in should be the same when queried.\n\n-Jason\n\n\n\n--\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\n-                                                               -\n- Jason Pyeron                      PD Inc. http://www.pdinc.us -\n- Principal Consultant              10 West 24th Street #100    -\n- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -\n-                                                               -\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\nThis message is copyright PD Inc, subject to license 20080407P00.\n"},{"id":"204087","messageId":"CAMP44s3yq-C7nYciONf=O61F9mceNV36A3XRPtXCrH=6m-ZpMg@mail.gmail.com","threadId":"32214","inReplyTo":"20121128011136.GA29674@thyrsus.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-28T01:36:05Z","receivedAt":"2012-11-28T01:36:05Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Nov 28, 2012 at 2:11 AM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com>:\n>> % git cat-file -p HEAD\n>>\n>> You'll see exactly how git stores commits. Changing anything in there\n>> must be done carefully.\n>\n> Oh, I've seen *that* before.  Are you telling me the database\n> representation is actually textual?\n\nhttp://git-scm.com/book/ch9-2.html\n\n---\n% ruby -e \"require 'zlib'; puts\nZlib::Inflate.inflate(File.read('.git/objects/55/47f28602c9b07f69dfa4685945f71f660e8b25'))\"\n\ncommit 382tree a14fe16bb9cb7d949d9eb7570bf56968b209f4a2\nparent c3640f09011d969ac85753c8f0114ce9b9c86603\nauthor Felipe Contreras <felipe.contreras@gmail.com> 1352767480 +0100\ncommitter Felipe Contreras <felipe.contreras@gmail.com> 1354064281 +0100\n\nremote-bzr: detect local repositories\n\nSo we don't create a clone  unnecessarily.\n\nSigned-off-by: Felipe Contreras <felipe.contreras@gmail.com>\n---\n\nYes, that's what I'm telling you.\n\n-- \nFelipe Contreras\n"},{"id":"204090","messageId":"CAMP44s1Kr0DGvqL5V3P-JD_aa5fbiyp2evCjBfZ7-X7nar_VnA@mail.gmail.com","threadId":"32214","inReplyTo":"20121128011750.GA23498@sigill.intra.peff.net","subject":"Re: Millisecond precision in timestamps?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-28T01:42:24Z","receivedAt":"2012-11-28T01:42:24Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Nov 28, 2012 at 2:17 AM, Jeff King <peff@peff.net> wrote:\n\n> But I really wonder if anybody actually cares about adding sub-second\n> timestamp support, or if it is merely \"because SVN has it\".\n\nI agree, I don't see any point.\n\n-- \nFelipe Contreras\n"},{"id":"204096","messageId":"7vk3t6jxjj.fsf@alter.siamese.dyndns.org","threadId":"32214","inReplyTo":"20121127230419.GA26080@thyrsus.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-28T02:01:20Z","receivedAt":"2012-11-28T02:01:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Eric S. Raymond\" <esr@thyrsus.com> writes:\n\n> Junio C Hamano <gitster@pobox.com>:\n>> fsck_ident() in fsck.c rejects anything but \" [1-9][0-9]* \" after\n>> the author and committer ident (i.e. the timestamp has to be\n>> integral number of seconds since the epoch, not before it, nor\n>> with fractional seconds).\n>\n> Is this architecturally significant?  It sounds like another\n> implementation detail.\n\nNo.\n\nIf you create a commit object that violatse it and have 47 million\nexisting users pull such a history, they not be able to use such a\nhistory with the version of Git they have.  Don't go there.\n\nAs somebody else mentioned, in distributed environment millisecond\ntimestamps won't have much meaning, so it looks like a very low\npriority to me from Git's perspective.\n"},{"id":"204117","messageId":"20121128032337.GB1669@thyrsus.com","threadId":"32214","inReplyTo":"20121128011750.GA23498@sigill.intra.peff.net","subject":"Re: Millisecond precision in timestamps?","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-28T03:23:37Z","receivedAt":"2012-11-28T03:23:37Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Jeff King <peff@peff.net>:\n> But I really wonder if anybody actually cares about adding sub-second\n> timestamp support, or if it is merely \"because SVN has it\".\n\nThere's actually one possible other reason to care.  1-second granularity \nisn't quite fine enough to guarantee that a (committer, timestamp)\npair is a unique key.  1 microsecond granularity would be.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204119","messageId":"20121128033009.GA3931@sigill.intra.peff.net","threadId":"32214","inReplyTo":"20121128032337.GB1669@thyrsus.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-28T03:30:09Z","receivedAt":"2012-11-28T03:30:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 27, 2012 at 10:23:37PM -0500, Eric S. Raymond wrote:\n\n> Jeff King <peff@peff.net>:\n> > But I really wonder if anybody actually cares about adding sub-second\n> > timestamp support, or if it is merely \"because SVN has it\".\n> \n> There's actually one possible other reason to care.  1-second granularity \n> isn't quite fine enough to guarantee that a (committer, timestamp)\n> pair is a unique key.  1 microsecond granularity would be.\n\nYou can't guarantee that such a pair is unique, anyway, due to clock\nskew.\n\nA much more compelling argument to me would be that you are doing some\nbidirectional magic between git and svn, and you want to make make sure\nthat an svn->git->svn translation will result in the exact same bytes.\nThen the argument is still \"because SVN has it\", but at least it is \"and\nwe interoperate with it\" and not simply chasing a cool but useless\nfeature.\n\n-Peff\n"},{"id":"204123","messageId":"CAMP44s1Kv4r+mq5Hr8-4gN6pZ+FO+zazu+YHO2O53X8iuT0GFQ@mail.gmail.com","threadId":"32214","inReplyTo":"20121128033009.GA3931@sigill.intra.peff.net","subject":"Re: Millisecond precision in timestamps?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-28T03:44:54Z","receivedAt":"2012-11-28T03:44:54Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Nov 28, 2012 at 4:30 AM, Jeff King <peff@peff.net> wrote:\n> On Tue, Nov 27, 2012 at 10:23:37PM -0500, Eric S. Raymond wrote:\n>\n>> Jeff King <peff@peff.net>:\n>> > But I really wonder if anybody actually cares about adding sub-second\n>> > timestamp support, or if it is merely \"because SVN has it\".\n>>\n>> There's actually one possible other reason to care.  1-second granularity\n>> isn't quite fine enough to guarantee that a (committer, timestamp)\n>> pair is a unique key.  1 microsecond granularity would be.\n>\n> You can't guarantee that such a pair is unique, anyway, due to clock\n> skew.\n>\n> A much more compelling argument to me would be that you are doing some\n> bidirectional magic between git and svn, and you want to make make sure\n> that an svn->git->svn translation will result in the exact same bytes.\n> Then the argument is still \"because SVN has it\", but at least it is \"and\n> we interoperate with it\" and not simply chasing a cool but useless\n> feature.\n\nBut the same can be said of mercurial and bzr. This can be solved\nattaching some external SCM information in notes, and somehow make\nfast-export throw that info along with the commit.\n\nFor now the solution has been to append the extra information into the\ncommit message, which is ugly and hacky, but it works.\n\n-- \nFelipe Contreras\n"},{"id":"204124","messageId":"20121128034700.GD1669@thyrsus.com","threadId":"32214","inReplyTo":"20121128033009.GA3931@sigill.intra.peff.net","subject":"Re: Millisecond precision in timestamps?","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-28T03:47:00Z","receivedAt":"2012-11-28T03:47:00Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Jeff King <peff@peff.net>:\n> A much more compelling argument to me would be that you are doing some\n> bidirectional magic between git and svn, and you want to make make sure\n> that an svn->git->svn translation will result in the exact same bytes.\n> Then the argument is still \"because SVN has it\", but at least it is \"and\n> we interoperate with it\" and not simply chasing a cool but useless\n> feature.\n\nEr, well, that *is* in fact the exact reason I want it.\n\nI didn't put it exactly that way because I didn't expect anyone here\nto particularly care about round-tripping like that.  But remember \nthat I do a lot of stuff with repo surgery and conversion tools.\n\nAs a matter of fact (and this list is the first to hear about it) \nI'm working on code right now that massages a git import stream\ninto a Subversion dumpfile.  Soon, unless I hit a blocker I'm\nnot expecting, I'll ship it.\n\nYes, there will be serious limitations and unavoidable metadata loss.\nBut in every case *except timestamps* that loss is Subversion's fault\nfor having a weak ontology.  Timestamps are the one place git doesn't \nhold up its end.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204126","messageId":"20121128040739.GA4115@sigill.intra.peff.net","threadId":"32214","inReplyTo":"20121128034700.GD1669@thyrsus.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-28T04:07:39Z","receivedAt":"2012-11-28T04:07:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 27, 2012 at 10:47:00PM -0500, Eric S. Raymond wrote:\n\n> Jeff King <peff@peff.net>:\n> > A much more compelling argument to me would be that you are doing some\n> > bidirectional magic between git and svn, and you want to make make sure\n> > that an svn->git->svn translation will result in the exact same bytes.\n> > Then the argument is still \"because SVN has it\", but at least it is \"and\n> > we interoperate with it\" and not simply chasing a cool but useless\n> > feature.\n> \n> Er, well, that *is* in fact the exact reason I want it.\n> \n> I didn't put it exactly that way because I didn't expect anyone here\n> to particularly care about round-tripping like that.  But remember \n> that I do a lot of stuff with repo surgery and conversion tools.\n\nIf that's what we really care about, then that opens up the\npossibilities for how we store the data. An extension header in the\nobject might be convenient, but it opens up a lot of questions about\nwhat git will do with such a header (e.g., would it be part of git-log\noutput?).\n\nFelipe suggested using git-notes to add the metadata, which I think is a\nreasonable first step. The git side of the code is already written, and\nthe concept is nicely modularized away from the core of git. Nobody has\nto care about it but your importer, and anybody who wants to query it[1]\ncan do so by requesting the note.\n\n-Peff\n\n[1] And you do not have to limit yourself to timestamps, if there is\n    other metadata about each commit you end up wanting to store for a\n    clean bi-directional conversion.\n"},{"id":"204128","messageId":"20121128042529.GA3864@thyrsus.com","threadId":"32214","inReplyTo":"20121128040739.GA4115@sigill.intra.peff.net","subject":"Re: Millisecond precision in timestamps?","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-28T04:25:30Z","receivedAt":"2012-11-28T04:25:30Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Jeff King <peff@peff.net>:\n> Felipe suggested using git-notes to add the metadata, which I think is a\n> reasonable first step. The git side of the code is already written, and\n> the concept is nicely modularized away from the core of git. Nobody has\n> to care about it but your importer, and anybody who wants to query it[1]\n> can do so by requesting the note.\n> \n> -Peff\n> \n> [1] And you do not have to limit yourself to timestamps, if there is\n>     other metadata about each commit you end up wanting to store for a\n>     clean bi-directional conversion.\n\nI have actually wanted something like this quite badly.  Not so much\nfor timestamps (though that would be nice), but it would be useful if\neach commit could carry a fossil-ID attribute that points at the\nSubversion commit it was derived from.\n\nI've tried to make notes work for this, but couldn't beat it into\ndoing what I was after.  Shawn, is there a way that the import stream\nsyntax can declare a note with in-line data attached to the commit where\nit's declared?  \n\nI tried just using the mark of the current commit, but git throws an error\nbecause it thinks that mark is not yet declared when the note fileop\nis parsed.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204139","messageId":"7v7gp6i3rx.fsf@alter.siamese.dyndns.org","threadId":"32214","inReplyTo":"20121128011750.GA23498@sigill.intra.peff.net","subject":"Re: Millisecond precision in timestamps?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-28T07:29:38Z","receivedAt":"2012-11-28T07:29:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> There is room for new headers, and older versions of git will ignore\n> them. You could add a new \"committer-timestamp\" field that elaborates on\n> the timestamp included on the committer line. Newer versions of git\n> would respect it, and older versions would fall back to using the\n> committer timestamp.\n>\n> But I really wonder if anybody actually cares about adding sub-second\n> timestamp support, or if it is merely \"because SVN has it\".\n\nRoundtrip conversions may benefit from sub-second timestamps, but\npersonally I think negative timestamps are more interesting and of\npractical use.  Prehistoric projects need them even if they intend\nto switch to Git, never to go back to their original tarballs and\ncollection of RCS ,v files.\n\nAnd if we were to add \"committer-timestamp\" and friends to support\nnegative timestamps anyway (because older tools will not support\nthem), supporting sub-second part might be something we want to\nthink about at the same time.\n\nWe would however need to be extra careful.  How should we express\nhalf-second past Tue Nov 27 23:24:16 2012 (US/Pacific)?  Would we\nspell it 1354087456.5?  1354087456.500?  Would we require decimal\nrepresentation of floating point numbers to be normalized in some\nway (e.g. minimum number of digits without losing precision)?  The\nsame timestamp needs to be expressed the same way, or we will end up\nwith different commit objects, which defeats the whole purpose of\nintroducing subsecond timestamps to support round-trip conversions.\n\nIf we were to use a separate \"subsecond\" fields, another thing we\nneed to be careful about is the order of these extra fields, exactly\nfor the same reason.\n"},{"id":"204143","messageId":"20121128075807.GA9912@thyrsus.com","threadId":"32214","inReplyTo":"7v7gp6i3rx.fsf@alter.siamese.dyndns.org","subject":"Re: Millisecond precision in timestamps?","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-28T07:58:08Z","receivedAt":"2012-11-28T07:58:08Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Junio C Hamano <gitster@pobox.com>:\n> Roundtrip conversions may benefit from sub-second timestamps, but\n> personally I think negative timestamps are more interesting and of\n> practical use. \n\nYou mean, as in times before the Unix epoch 1970-01-01T00:00:00Z?  \n\nInteresting.  I hadn't thought of that.  I've never seen a software\nproject under version control with bits that old, which is significant\nbecause I've probably done more digging into ancient software than\nanybody other than a specialist historian or two.\n\nThey would have to have been restrospective dates from the get-go.\nSCCS wasn't built until 1972.\n\n> And if we were to add \"committer-timestamp\" and friends to support\n> negative timestamps anyway (because older tools will not support\n> them), supporting sub-second part might be something we want to\n> think about at the same time.\n\nThat seems eminently reasonable.\n\n> We would however need to be extra careful.  How should we express\n> half-second past Tue Nov 27 23:24:16 2012 (US/Pacific)?  Would we\n> spell it 1354087456.5?  1354087456.500?  Would we require decimal\n> representation of floating point numbers to be normalized in some\n> way (e.g. minimum number of digits without losing precision)?  The\n> same timestamp needs to be expressed the same way, or we will end up\n> with different commit objects, which defeats the whole purpose of\n> introducing subsecond timestamps to support round-trip conversions.\n> \n> If we were to use a separate \"subsecond\" fields, another thing we\n> need to be careful about is the order of these extra fields, exactly\n> for the same reason.\n\nI think minimum number of digits without losing precision is about the\nonly alternative that is future-proof - I was going to suggest it for\nthat reason.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204145","messageId":"CAJDDKr6n2KSZz5zPHeWiYHAP7Zr02Ti-e24AX1yR_XAXAKhscg@mail.gmail.com","threadId":"32214","inReplyTo":"20121128075807.GA9912@thyrsus.com","subject":"Re: Millisecond precision in timestamps?","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2012-11-28T08:04:13Z","receivedAt":"2012-11-28T08:04:13Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Tue, Nov 27, 2012 at 11:58 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n> Junio C Hamano <gitster@pobox.com>:\n>> Roundtrip conversions may benefit from sub-second timestamps, but\n>> personally I think negative timestamps are more interesting and of\n>> practical use.\n>\n> You mean, as in times before the Unix epoch 1970-01-01T00:00:00Z?\n>\n> Interesting.  I hadn't thought of that.  I've never seen a software\n> project under version control with bits that old, which is significant\n> because I've probably done more digging into ancient software than\n> anybody other than a specialist historian or two.\n\nOne example I've heard is someone wanting to throw the history\nof a country's laws into git so they can diff them.\n-- \nDavid\n"},{"id":"204146","messageId":"CABYiQpmEpdf3L56NYSvPWovNOs_ifqj5QctuPSMoygHyMrz8+g@mail.gmail.com","threadId":"32214","inReplyTo":"7v7gp6i3rx.fsf@alter.siamese.dyndns.org","subject":"Re: Millisecond precision in timestamps?","fromName":"Thomas Berg","fromEmail":"merlin66b@gmail.com","sentAt":"2012-11-28T08:19:53Z","receivedAt":"2012-11-28T08:19:53Z","isPatch":false,"sender":{"key":"merlin66b@gmail.com","avatar":null},"body":"On Wed, Nov 28, 2012 at 8:29 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>> There is room for new headers, and older versions of git will ignore\n>> them. You could add a new \"committer-timestamp\" field that elaborates on\n>> the timestamp included on the committer line. Newer versions of git\n>> would respect it, and older versions would fall back to using the\n>> committer timestamp.\n>>\n>> But I really wonder if anybody actually cares about adding sub-second\n>> timestamp support, or if it is merely \"because SVN has it\".\n>\n> Roundtrip conversions may benefit from sub-second timestamps, but\n> personally I think negative timestamps are more interesting and of\n> practical use.  Prehistoric projects need them even if they intend\n> to switch to Git, never to go back to their original tarballs and\n> collection of RCS ,v files.\n\nIf roundtripping to other version control systems is an argument,\nadding sub-second timestamps could potentially create as many problems\nas it solves. For example, I've been using the hg-git bridge, and it\nsupports roundtripping between git and mercurial today (for most repos\nI've tried anyway). I may have missed something, but this could imply\nthat mercurial doesn't care about sub-second timestamps either. If so,\nand if git suddenly were to record it, it would no longer be as\nstraight forward to represent git history in hg.\n\nIn my opinion it would be a shame to sacrifice this compatibility just\nto reduce the distance to svn, which is much larger anyway.\n\n- Thomas\n"},{"id":"204147","messageId":"CAMP44s3MPMySnwjWjzo4aRX05u05xratgiyiYJUYPmnV2WK6kQ@mail.gmail.com","threadId":"32214","inReplyTo":"CABYiQpmEpdf3L56NYSvPWovNOs_ifqj5QctuPSMoygHyMrz8+g@mail.gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-28T08:44:56Z","receivedAt":"2012-11-28T08:44:56Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Nov 28, 2012 at 9:19 AM, Thomas Berg <merlin66b@gmail.com> wrote:\n> On Wed, Nov 28, 2012 at 8:29 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Jeff King <peff@peff.net> writes:\n>>\n>>> There is room for new headers, and older versions of git will ignore\n>>> them. You could add a new \"committer-timestamp\" field that elaborates on\n>>> the timestamp included on the committer line. Newer versions of git\n>>> would respect it, and older versions would fall back to using the\n>>> committer timestamp.\n>>>\n>>> But I really wonder if anybody actually cares about adding sub-second\n>>> timestamp support, or if it is merely \"because SVN has it\".\n>>\n>> Roundtrip conversions may benefit from sub-second timestamps, but\n>> personally I think negative timestamps are more interesting and of\n>> practical use.  Prehistoric projects need them even if they intend\n>> to switch to Git, never to go back to their original tarballs and\n>> collection of RCS ,v files.\n>\n> If roundtripping to other version control systems is an argument,\n> adding sub-second timestamps could potentially create as many problems\n> as it solves. For example, I've been using the hg-git bridge, and it\n> supports roundtripping between git and mercurial today (for most repos\n> I've tried anyway). I may have missed something, but this could imply\n> that mercurial doesn't care about sub-second timestamps either. If so,\n> and if git suddenly were to record it, it would no longer be as\n> straight forward to represent git history in hg.\n\nI'm not entirely sure. The API seems to return a float for the time,\nbut at least as far I can see, it never has any decimals anyway.\n\nBut it doesn't really matter, mercurial doesn't have a committer\ninformation either. This is solved by tools like hg-git by storing the\ninformation in an 'extra' field, which can store anything.\n\nUnfortunately git doesn't have a similar field, so people have been\nusing the commit message to store extra information.\n\nEither way, I don't see the point in changing git's commit format for\nexternal tools. The git-notes functionality works just fine for that,\nit just needs to be attached in the relevant places, like 'git\nfast-export'.\n\nBTW. Have you checked git's native support for hg?[1]\n\nCheers.\n\n[1] http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/\n\n-- \nFelipe Contreras\n"},{"id":"204149","messageId":"CABYiQpnEZECU5Vj5JzMimtw-CAJQz2d=3rii4gM6d37wCnO5AA@mail.gmail.com","threadId":"32214","inReplyTo":"CAMP44s3MPMySnwjWjzo4aRX05u05xratgiyiYJUYPmnV2WK6kQ@mail.gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Thomas Berg","fromEmail":"merlin66b@gmail.com","sentAt":"2012-11-28T09:10:24Z","receivedAt":"2012-11-28T09:10:24Z","isPatch":false,"sender":{"key":"merlin66b@gmail.com","avatar":null},"body":"On Wed, Nov 28, 2012 at 9:44 AM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n>> If roundtripping to other version control systems is an argument,\n>> adding sub-second timestamps could potentially create as many problems\n>> as it solves. For example, I've been using the hg-git bridge, and it\n>> supports roundtripping between git and mercurial today (for most repos\n>> I've tried anyway). I may have missed something, but this could imply\n>> that mercurial doesn't care about sub-second timestamps either. If so,\n>> and if git suddenly were to record it, it would no longer be as\n>> straight forward to represent git history in hg.\n>\n> I'm not entirely sure. The API seems to return a float for the time,\n> but at least as far I can see, it never has any decimals anyway.\n>\n> But it doesn't really matter, mercurial doesn't have a committer\n> information either. This is solved by tools like hg-git by storing the\n> information in an 'extra' field, which can store anything.\n\nTrue. For many commits though, hg-git doesn't need any extra fields,\nas far as I've seen. A timestamp incompatibility would require extra\ninfo on every commit.\n\n> Either way, I don't see the point in changing git's commit format for\n> external tools. The git-notes functionality works just fine for that,\n> it just needs to be attached in the relevant places, like 'git\n> fast-export'.\n\nI agree. Even encoding info in the commit message works fine, and\ngit-svn already does that.\n\n> BTW. Have you checked git's native support for hg?[1]\n\nThat's been added after I played with this last, I'll have a look.\n\nCheers,\nThomas\n"},{"id":"204151","messageId":"50B5E30B.5080505@op5.se","threadId":"32214","inReplyTo":"7v7gp6i3rx.fsf@alter.siamese.dyndns.org","subject":"Re: Millisecond precision in timestamps?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2012-11-28T10:10:19Z","receivedAt":"2012-11-28T10:10:19Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 11/28/2012 08:29 AM, Junio C Hamano wrote:\n> Jeff King <peff@peff.net> writes:\n> \n>> There is room for new headers, and older versions of git will ignore\n>> them. You could add a new \"committer-timestamp\" field that elaborates on\n>> the timestamp included on the committer line. Newer versions of git\n>> would respect it, and older versions would fall back to using the\n>> committer timestamp.\n>>\n>> But I really wonder if anybody actually cares about adding sub-second\n>> timestamp support, or if it is merely \"because SVN has it\".\n> \n> Roundtrip conversions may benefit from sub-second timestamps, but\n> personally I think negative timestamps are more interesting and of\n> practical use.  Prehistoric projects need them even if they intend\n> to switch to Git, never to go back to their original tarballs and\n> collection of RCS ,v files.\n> \n> And if we were to add \"committer-timestamp\" and friends to support\n> negative timestamps anyway (because older tools will not support\n> them), supporting sub-second part might be something we want to\n> think about at the same time.\n> \n> We would however need to be extra careful.  How should we express\n> half-second past Tue Nov 27 23:24:16 2012 (US/Pacific)?  Would we\n> spell it 1354087456.5?  1354087456.500?  Would we require decimal\n> representation of floating point numbers to be normalized in some\n> way (e.g. minimum number of digits without losing precision)?  The\n> same timestamp needs to be expressed the same way, or we will end up\n> with different commit objects, which defeats the whole purpose of\n> introducing subsecond timestamps to support round-trip conversions.\n> \n> If we were to use a separate \"subsecond\" fields, another thing we\n> need to be careful about is the order of these extra fields, exactly\n> for the same reason.\n> \n\nIf we're going to support pre-epoch timestamps, we'll have to do that\nfor 2.0 anyway, since we'll otherwise have two conflicting dates in\nthe commit object.\n\nAdding support for parsing them now and start writing them in 2.0\nwould make sense.\n\nIn that case, we'd have to print timestamps as\nprintf(\"%lu.%06lu\", tv.tv_sec, tv.tv_usec);\n\nI'm unsure how useful it is to support pre-epoch dates though. It's\nhard to find software where anyone really cares about the code from\n43 years ago with anything but historical interest, and for those\nwho take the museum road, I'm betting it's more interesting to see\nhow people worked back then than it is to see what they wrote.\n\nAside from that, it would be trivial to support museum style history\nviewing with a special flag that treats the timestamps as minutes\nsince 1900-01-01 or some such, giving us plenty of time before even\nthe first punch-card was invented. It wouldn't be much harder to\nlet the user specify the timeunit and the start-point either, and\nthen we could store the history of carbon-based lifeforms on earth\nin git.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"204152","messageId":"50B5E3F0.4050703@op5.se","threadId":"32214","inReplyTo":"CAJDDKr6n2KSZz5zPHeWiYHAP7Zr02Ti-e24AX1yR_XAXAKhscg@mail.gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2012-11-28T10:14:08Z","receivedAt":"2012-11-28T10:14:08Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 11/28/2012 09:04 AM, David Aguilar wrote:\n> On Tue, Nov 27, 2012 at 11:58 PM, Eric S. Raymond <esr@thyrsus.com> wrote:\n>> Junio C Hamano <gitster@pobox.com>:\n>>> Roundtrip conversions may benefit from sub-second timestamps, but\n>>> personally I think negative timestamps are more interesting and of\n>>> practical use.\n>>\n>> You mean, as in times before the Unix epoch 1970-01-01T00:00:00Z?\n>>\n>> Interesting.  I hadn't thought of that.  I've never seen a software\n>> project under version control with bits that old, which is significant\n>> because I've probably done more digging into ancient software than\n>> anybody other than a specialist historian or two.\n> \n> One example I've heard is someone wanting to throw the history\n> of a country's laws into git so they can diff them.\n> \n\nThat'll get tricky if you try it in Sweden. Our oldest written law\ndates back to 1281. Quite fun reading. Apparently it was against the\nlaw to shoot your slaves with stone arrows back then.\n\nSee my other proposal for how this could be done, which would only\naffect the output layer (and some care would have to be taken with\nthe input, naturally).\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"204172","messageId":"7vobihvcdk.fsf@alter.siamese.dyndns.org","threadId":"32214","inReplyTo":"CABYiQpmEpdf3L56NYSvPWovNOs_ifqj5QctuPSMoygHyMrz8+g@mail.gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-28T17:57:43Z","receivedAt":"2012-11-28T17:57:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Berg <merlin66b@gmail.com> writes:\n\n> If roundtripping to other version control systems is an argument,\n> adding sub-second timestamps could potentially create as many problems\n> as it solves. For example, I've been using the hg-git bridge, and it\n> supports roundtripping between git and mercurial today (for most repos\n> I've tried anyway). I may have missed something,...\n\nWhat I left unsaid was that the use of extra subsecond resolution is\noptional.  I do not see any reason for *us* to create commits with\nsubsecond resolution when we are writing native commits.  Only when\nthe end users and/or import tools tell us to.  If you assume all\nforeign SCM you care about have at least one second resolution, you\nwould be fine.\n\nHaving said all that, given that this, if implemented, would not be\nused by us but only for recording other people's times, and that the\nset of meta information we record in our history will never be\nsuperset of everybody else's anyway, I do not see much point in\nsupporting subsecond timestamps in the first place.\n"},{"id":"204236","messageId":"20121129061650.GB25537@thyrsus.com","threadId":"32214","inReplyTo":"E4C993F4-B7A4-4CB6-A9EA-BFE98BE3A381@gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-29T06:16:50Z","receivedAt":"2012-11-29T06:16:50Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Steven Michalske <smichalske@gmail.com>:\n> Would having arbitrary key value pairs be useful in the git data\n> model?  We could have ones that affect the sha1 and others that are\n> transparent.\n\nMy tools would have several uses for these.\n\nbzr's implementation of import streams has a commit-propperties extension.\nreposurgeon can read, display.. and manipulate these key/value pairs.\nI do wish they were in core git.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204237","messageId":"7va9u0sx26.fsf@alter.siamese.dyndns.org","threadId":"32214","inReplyTo":"E4C993F4-B7A4-4CB6-A9EA-BFE98BE3A381@gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-29T07:11:29Z","receivedAt":"2012-11-29T07:11:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Michalske <smichalske@gmail.com> writes:\n\n> Would having arbitrary key value pairs be useful in the git data\n> model?\n\nMy answer to the question is that it is harmful to the data model,\nbut the benefit of going against the data model _may_ outweigh the\ndownside.  It is all relative.\n\nThe first of very small number of principles of the git data model\nis that the object name is derived solely from the contents, hence\nwe can tell two different things apart with object names without\nlooking at object contents.\n\nThis is actively broken by adding \"junk\" fields left and right.\nAdding arbitrary pieces of data that are optional (and largely\nignored by core operations) means you can record objects with\nessentially the same contents under different object names, so\nobject names no longer help us telling two moral-equivalent objects\napart.\n\nBut \"if two objects have different names, they are not the same\"\ndoes not have to be the only and the absolute truth in all contexts;\nthe world is not so black and white.  Depending on the application\nand the context, you may want to treat two things that are not the\nsame as equivalents.\n\nFor example, at the blob level, two blob objects that store the same\ntext (say, one original and the other typed in double-space) would\nbe different objects and have different object names, but you may\nwant to treat them as \"equivalents\" (not same but interchangeable),\nby applying textconv filter to normalize their contents when\ncomparing them.  We still keep the \"two objects with different names\nare different\" principle, but at the same time, allow users to treat\nthem as equivalent in specific contexts.\n\nIntroducing a hack to exclude selective \"junk\" fields from hashing\ndone for object name computation is not a solution and is out of the\nquestion, but that does not necessarily mean that commit objects\nshould never be extended with new types of header fields.  When a\ncommit object is made with a \"junk\" field, it will have a name that\nis different from the one it would get without the \"junk\" field, but\nthe benefit of the ability to store extra data _may_ outweigh the\ndownside of having to always compare the contents of two objects\nwith different names to find out that they are different but\nequivalent.\n"},{"id":"204238","messageId":"CAMP44s3ShoR7iR5QLYn_u+u_nNGnS1jumpt+iseWYKx0PX9UEA@mail.gmail.com","threadId":"32214","inReplyTo":"7va9u0sx26.fsf@alter.siamese.dyndns.org","subject":"Re: Millisecond precision in timestamps?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-29T07:22:14Z","receivedAt":"2012-11-29T07:22:14Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Steven Michalske <smichalske@gmail.com> writes:\n>\n>> Would having arbitrary key value pairs be useful in the git data\n>> model?\n>\n> My answer to the question is that it is harmful to the data model,\n> but the benefit of going against the data model _may_ outweigh the\n> downside.  It is all relative.\n\nIf git doesn't provide the capability, people will keep using the\ncommit message to store that extra information, which I would think is\neven more harmful. An standard 'commit-extra' note or something would\nhelp deal with that.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"204246","messageId":"20121129103847.GA9264@thyrsus.com","threadId":"32214","inReplyTo":"CAMP44s3ShoR7iR5QLYn_u+u_nNGnS1jumpt+iseWYKx0PX9UEA@mail.gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-29T10:38:47Z","receivedAt":"2012-11-29T10:38:47Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com>:\n> On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> > Steven Michalske <smichalske@gmail.com> writes:\n> >\n> >> Would having arbitrary key value pairs be useful in the git data\n> >> model?\n> >\n> > My answer to the question is that it is harmful to the data model,\n> > but the benefit of going against the data model _may_ outweigh the\n> > downside.  It is all relative.\n> \n> If git doesn't provide the capability, people will keep using the\n> commit message to store that extra information, which I would think is\n> even more harmful. An standard 'commit-extra' note or something would\n> help deal with that.\n\nAgreed.  \n\nMy use case for a capability like this is one of the more common ones.\nI want to be able to store a fossil commit-ID inherited from another\nVCS outside the commit comment.  The absence of a key/value store forces\nme into some annoying kludges.\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204263","messageId":"7vtxs8qs1r.fsf@alter.siamese.dyndns.org","threadId":"32214","inReplyTo":"20121129103847.GA9264@thyrsus.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-29T16:42:40Z","receivedAt":"2012-11-29T16:42:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Eric S. Raymond\" <esr@thyrsus.com> writes:\n\n> Felipe Contreras <felipe.contreras@gmail.com>:\n>> On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> > Steven Michalske <smichalske@gmail.com> writes:\n>> >\n>> >> Would having arbitrary key value pairs be useful in the git data\n>> >> model?\n>> >\n>> > My answer to the question is that it is harmful to the data model,\n>> > but the benefit of going against the data model _may_ outweigh the\n>> > downside.  It is all relative.\n>\n> My use case for a capability like this is one of the more common ones.\n> I want to be able to store a fossil commit-ID inherited from another\n> VCS outside the commit comment.\n\nThat is exactly why I said it is all relative.  If it helps your\napplication, you can weigh the pros-and-cons yourself and choose to\nthrow \"junk\" extended header fields in the commit objects you\ncreate, using hash-object (or commit-tree).  You can read it out\nusing cat-file and do whatever you want to do with it, and modern\nGit (v1.5.0 was from early 2007) and tools that are designed to work\nwith Git know to ignore such \"junk\" field.\n\n> The absence of a key/value store forces me into some annoying\n> kludges.\n\nDo not do annoying kludge, then.  Come up with a method to encode\nyour list of (key,value) tuples into a single string, throw a\ncustom extra header after all the standard header fields in, perhaps\nlike this:\n\n    tree 0664b9c82d87269b335ff78f32d0e4a504f58cfc\n    author A U Thor <author@example.xz> 1355999999 +0900\n    committer C O Mitter <committer@example.xz> 1355999999 +0900\n    encoding iso-2022-jp\n    reposurgeon-metadata your-serialized-list-of-key-value-tuples\n     second-line-of-such-serialization\n     third-line-of-such-serialization\n\n    My first commit\n\n    Signed-off-by: A U Thor <author@example.xz>\n    Signed-off-by: C O Mitter <committer@example.xz>\n"},{"id":"204281","messageId":"20121129190205.GA11629@thyrsus.com","threadId":"32214","inReplyTo":"7vtxs8qs1r.fsf@alter.siamese.dyndns.org","subject":"Re: Millisecond precision in timestamps?","fromName":"Eric S. Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2012-11-29T19:02:05Z","receivedAt":"2012-11-29T19:02:05Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Junio C Hamano <gitster@pobox.com>:\n> That is exactly why I said it is all relative.  If it helps your\n> application, you can weigh the pros-and-cons yourself and choose to\n> throw \"junk\" extended header fields in the commit objects you\n> create, using hash-object (or commit-tree).  You can read it out\n> using cat-file and do whatever you want to do with it, and modern\n> Git (v1.5.0 was from early 2007) and tools that are designed to work\n> with Git know to ignore such \"junk\" field.\n\nA good start.  But remember that reposurgeon's entire interface to the\ngit object level is through fast-export/fast-import.  I need import-\nstream syntax for these.\n\nbzr's syntax would do:\n\n-------------------------------------------\nmark :1\ncommitter Eric S. Raymond <esr@thyrsus.com> 1289147634 -0500\ndata 14\nFirst commit.\n\nproperty branch-nick 12 bzr-testrepo\nM 644 inline README\ndata 41\nThis is a test file in a dummy bzr repo.\n-------------------------------------------\n\nIf we actually care about keys being full utf-8 with embedded whitespace\nit should look more like this:\n\n-------------------------------------------\nmark :1\ncommitter Eric S. Raymond <esr@thyrsus.com> 1289147634 -0500\ndata 14\nFirst commit.\n\nproperty 11\nbranch-nick\npropval 12 \nbzr-testrepo\nM 644 inline README\ndata 41\nThis is a test file in a dummy bzr repo.\n-------------------------------------------\n-- \n\t\t<a href=\"http://www.catb.org/~esr/\">Eric S. Raymond</a>\n"},{"id":"204287","messageId":"CABURp0pnGYykud1xDn5T+eszQGTrzKLTp6J_O7ZrWwVd-zKpkg@mail.gmail.com","threadId":"32214","inReplyTo":"7v7gp6i3rx.fsf@alter.siamese.dyndns.org","subject":"Re: Millisecond precision in timestamps?","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-11-29T19:14:40Z","receivedAt":"2012-11-29T19:14:40Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Wed, Nov 28, 2012 at 2:29 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jeff King <peff@peff.net> writes:\n>\n>> There is room for new headers, and older versions of git will ignore\n>> them. You could add a new \"committer-timestamp\" field that elaborates on\n>> the timestamp included on the committer line. Newer versions of git\n>> would respect it, and older versions would fall back to using the\n>> committer timestamp.\n>>\n>> But I really wonder if anybody actually cares about adding sub-second\n>> timestamp support, or if it is merely \"because SVN has it\".\n>\n> Roundtrip conversions may benefit from sub-second timestamps, but\n> personally I think negative timestamps are more interesting and of\n> practical use.  Prehistoric projects need them even if they intend\n> to switch to Git, never to go back to their original tarballs and\n> collection of RCS ,v files.\n>\n> And if we were to add \"committer-timestamp\" and friends to support\n> negative timestamps anyway (because older tools will not support\n> them), supporting sub-second part might be something we want to\n> think about at the same time.\n\nPosix-time is signed, but I suppose the git tools do not expect/allow\na '-' character in the stream.  Has git considered the year-2038\nproblem?\n\nNo hurry...\n\nPhil\n"},{"id":"204293","messageId":"20121129200143.GB22084@sigill.intra.peff.net","threadId":"32214","inReplyTo":"CABURp0pnGYykud1xDn5T+eszQGTrzKLTp6J_O7ZrWwVd-zKpkg@mail.gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-11-29T20:01:43Z","receivedAt":"2012-11-29T20:01:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 29, 2012 at 02:14:40PM -0500, Phil Hord wrote:\n\n> > And if we were to add \"committer-timestamp\" and friends to support\n> > negative timestamps anyway (because older tools will not support\n> > them), supporting sub-second part might be something we want to\n> > think about at the same time.\n> \n> Posix-time is signed, but I suppose the git tools do not expect/allow\n> a '-' character in the stream.  Has git considered the year-2038\n> problem?\n\nYes. The timestamp is in base-10 ASCII, so there is no Y2038 problem in\nthe data format (it is up to the implementation to read it into a\nsufficiently large time_t internally, of course[1]).\n\nBut negative timestamps are a different story. We use \"unsigned long\"\ninternally for timestamps, and fsck will complain about it.\n\n-Peff\n\n[1] We use \"unsigned long\", which means we are Y2038-fine on I32/LP64\n    systems, but not on 32-bit or IL32/LLP64 systems. I do not use\n    Windows, but my understanding is that LLP64 is the norm there, so it\n    would eventually be a problem. But since we are unsigned, it is\n    actually a Y2106 problem.\n"},{"id":"204545","messageId":"2439538.19317881.1354750621740.JavaMail.root@dewire.com","threadId":"32214","inReplyTo":"CAJDDKr6n2KSZz5zPHeWiYHAP7Zr02Ti-e24AX1yR_XAXAKhscg@mail.gmail.com","subject":"Re: Millisecond precision in timestamps?","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2012-12-05T23:37:01Z","receivedAt":"2012-12-05T23:37:01Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"\n\n----- Ursprungligt meddelande -----\n> On Tue, Nov 27, 2012 at 11:58 PM, Eric S. Raymond <esr@thyrsus.com>\n> wrote:\n> > Junio C Hamano <gitster@pobox.com>:\n> >> Roundtrip conversions may benefit from sub-second timestamps, but\n> >> personally I think negative timestamps are more interesting and of\n> >> practical use.\n> >\n> > You mean, as in times before the Unix epoch 1970-01-01T00:00:00Z?\n> >\n> > Interesting.  I hadn't thought of that.  I've never seen a software\n> > project under version control with bits that old, which is\n> > significant\n> > because I've probably done more digging into ancient software than\n> > anybody other than a specialist historian or two.\n> \n> One example I've heard is someone wanting to throw the history\n> of a country's laws into git so they can diff them.\n\nNot sure any laws were passed on Feb 30th 1712 in sweden, but perhaps\nyou can define new time zones to handle that, but I doubt it is practically\ndoable when you get to countries and regions with less precise boundaries.\n\nSeconds-since as a representation for dates is a dangerous and very\nmessy game. Java gets it wrong somewhere in 1910 and my guess is others\nget it wrong too. There is change in time zones which triggers the bug.\n\n-- robin\n"},{"id":"204666","messageId":"m31uexsk1f.fsf@carbon.jhcloos.org","threadId":"32214","inReplyTo":"20121128075807.GA9912@thyrsus.com","subject":"Re: Millisecond precision in timestamps?","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2012-12-10T20:56:19Z","receivedAt":"2012-12-10T20:56:19Z","isPatch":false,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":">>>>> \"ESR\" == Eric S Raymond <esr@thyrsus.com> writes:\n\nESR> I've never seen a software project under version control with bits\nESR> that old,\n\nThey do exist, but the vcs timestamps are (at least for those in git :)\nnot (always) correlated to when the files were first added to the project.\n\nMaxima, as an example, has code which was written in the '60s.  (A\ncouple of years ago a bug was fixed in a contrib module which had\nbeen added to MACSYMA back in '62 or so.)\n\nI beleive axiom also has some similarly ancient code.\n\nThose two are now managed in git.  (Except for the openaxiom fork.)\n\nAnd there is a high-energy physics package still under development\nwith code going back to the '50s.  I'm pretty sure they moved to a\nvcs sometime in the last decade or two. :)\n\n-JimC\n-- \nJames Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6\n"}]}