Re: Millisecond precision in timestamps?

"Eric S. Raymond" [off-list ref] writes:

Felipe Contreras [off-list ref]:

quoted

On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano [off-list ref] wrote:

quoted

Steven Michalske [off-list ref] writes:

quoted

Would having arbitrary key value pairs be useful in the git data
model?

My answer to the question is that it is harmful to the data model,
but the benefit of going against the data model _may_ outweigh the
downside.  It is all relative.

My use case for a capability like this is one of the more common ones.
I want to be able to store a fossil commit-ID inherited from another
VCS outside the commit comment.

That is exactly why I said it is all relative.  If it helps your
application, you can weigh the pros-and-cons yourself and choose to
throw "junk" extended header fields in the commit objects you
create, using hash-object (or commit-tree).  You can read it out
using cat-file and do whatever you want to do with it, and modern
Git (v1.5.0 was from early 2007) and tools that are designed to work
with Git know to ignore such "junk" field.

The absence of a key/value store forces me into some annoying
kludges.

Do not do annoying kludge, then.  Come up with a method to encode
your list of (key,value) tuples into a single string, throw a
custom extra header after all the standard header fields in, perhaps
like this:

    tree 0664b9c82d87269b335ff78f32d0e4a504f58cfc
    author A U Thor [off-list ref] 1355999999 +0900
    committer C O Mitter [off-list ref] 1355999999 +0900
    encoding iso-2022-jp
    reposurgeon-metadata your-serialized-list-of-key-value-tuples
     second-line-of-such-serialization
     third-line-of-such-serialization

    My first commit

    Signed-off-by: A U Thor [off-list ref]
    Signed-off-by: C O Mitter [off-list ref]

Junio C Hamano [off-list ref]:

That is exactly why I said it is all relative.  If it helps your
application, you can weigh the pros-and-cons yourself and choose to
throw "junk" extended header fields in the commit objects you
create, using hash-object (or commit-tree).  You can read it out
using cat-file and do whatever you want to do with it, and modern
Git (v1.5.0 was from early 2007) and tools that are designed to work
with Git know to ignore such "junk" field.

A good start.  But remember that reposurgeon's entire interface to the
git object level is through fast-export/fast-import.  I need import-
stream syntax for these.

bzr's syntax would do:

-------------------------------------------
mark :1
committer Eric S. Raymond [off-list ref] 1289147634 -0500
data 14
First commit.

property branch-nick 12 bzr-testrepo
M 644 inline README
data 41
This is a test file in a dummy bzr repo.
-------------------------------------------

If we actually care about keys being full utf-8 with embedded whitespace
it should look more like this:

-------------------------------------------
mark :1
committer Eric S. Raymond [off-list ref] 1289147634 -0500
data 14
First commit.

property 11
branch-nick
propval 12 
bzr-testrepo
M 644 inline README
data 41
This is a test file in a dummy bzr repo.
-------------------------------------------
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>