> -----Original Message----- > From: Jeff King > Sent: Tuesday, November 27, 2012 20:18 > > On Tue, Nov 27, 2012 at 05:07:34PM -0800, Shawn O. Pearce wrote: > > > On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras > > <felipe.contre...@gmail.com> wrote: > > > On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond > <e...@thyrsus.com> wrote: > > >> Shawn Pearce <spea...@spearce.org>: > > >>> Well... if we added a fractional seconds to a commit, older > > >>> versions of Git will scream loudly and refuse to work > with the new > > >>> commit. That would create a fork of Git. > > >> > > >> So much for that idea, I guess. > > >> > > >> Unless..I don't know how git's database representations > work. Are > > >> they version-stamped in any way? If so, some slightly painful > > >> hackery would get around that problem. > > > > > > % git cat-file -p HEAD > > > > > > You'll see exactly how git stores commits. Changing anything in > > > there must be done carefully. > > > > Apparently there is no room to change in these fields > without breaking > > compatibility with all current versions of Git. So its not > just done > > carefully... its deciding to make Git 2.0 that is not > compatible with > > any Git 1.x release. > > There is room for new headers, and older versions of git will > ignore them. You could add a new "committer-timestamp" field > that elaborates on the timestamp included on the committer > line. Newer versions of git would respect it, and older > versions would fall back to using the committer timestamp.
Suggestion add a ms offset field. Ex: jpyeron@black /projects/git/git $ git cat-file -p HEAD tree 1e24acfbfcc05aa57e8cb2cfe3ffe01cb100961d parent e98fa647aa5673cc95b6e9be1fdc13c0afa2cb37 author Junio C Hamano <gits...@pobox.com> 1350495361 -0700 committer Junio C Hamano <gits...@pobox.com> 1350495402 -0700 mstimestamps author 0 committer 1234 Git 188.8.131.52 Signed-off-by: Junio C Hamano <gits...@pobox.com> > > But I really wonder if anybody actually cares about adding > sub-second timestamp support, or if it is merely "because SVN has it". Not because subversion has it but because date != git(precisedate) and some automation using git in a larger enterprise workflow may assume that date 1354065991.1234 going in should be the same when queried. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html