> "ESR" == Eric S Raymond writes:
ESR> I've never seen a software project under version control with bits
ESR> that old,
They do exist, but the vcs timestamps are (at least for those in git :)
not (always) correlated to when the files were first added to the project.
Maxima, as an example,
- Ursprungligt meddelande -
> On Tue, Nov 27, 2012 at 11:58 PM, Eric S. Raymond
> wrote:
> > Junio C Hamano :
> >> Roundtrip conversions may benefit from sub-second timestamps, but
> >> personally I think negative timestamps are more interesting and of
> >> practical use.
> >
> > You mea
On Thu, Nov 29, 2012 at 02:14:40PM -0500, Phil Hord wrote:
> > And if we were to add "committer-timestamp" and friends to support
> > negative timestamps anyway (because older tools will not support
> > them), supporting sub-second part might be something we want to
> > think about at the same tim
On Wed, Nov 28, 2012 at 2:29 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> 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
>
Junio C Hamano :
> 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-fi
"Eric S. Raymond" writes:
> Felipe Contreras :
>> On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano wrote:
>> > Steven Michalske writes:
>> >
>> >> 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 m
Felipe Contreras :
> On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano wrote:
> > Steven Michalske writes:
> >
> >> 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 ag
On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano wrote:
> Steven Michalske writes:
>
>> 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
Steven Michalske writes:
> 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.
The first of very small numbe
Steven Michalske :
> Would having arbitrary key value pairs be useful in the git data
> model? We could have ones that affect the sha1 and others that are
> transparent.
My tools would have several uses for these.
bzr's implementation of import streams has a commit-propperties extension.
reposur
Thomas Berg writes:
> If roundtripping to other version control systems is an argument,
> adding sub-second timestamps could potentially create as many problems
> as it solves. For example, I've been using the hg-git bridge, and it
> supports roundtripping between git and mercurial today (for mos
On 11/28/2012 09:04 AM, David Aguilar wrote:
> On Tue, Nov 27, 2012 at 11:58 PM, Eric S. Raymond wrote:
>> Junio C Hamano :
>>> Roundtrip conversions may benefit from sub-second timestamps, but
>>> personally I think negative timestamps are more interesting and of
>>> practical use.
>>
>> You mean
On 11/28/2012 08:29 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> 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 r
On Wed, Nov 28, 2012 at 9:44 AM, Felipe Contreras
wrote:
>> If roundtripping to other version control systems is an argument,
>> adding sub-second timestamps could potentially create as many problems
>> as it solves. For example, I've been using the hg-git bridge, and it
>> supports roundtripping
On Wed, Nov 28, 2012 at 9:19 AM, Thomas Berg wrote:
> On Wed, Nov 28, 2012 at 8:29 AM, Junio C Hamano wrote:
>> Jeff King writes:
>>
>>> 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 times
On Wed, Nov 28, 2012 at 8:29 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> 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
>
On Tue, Nov 27, 2012 at 11:58 PM, Eric S. Raymond wrote:
> Junio C Hamano :
>> Roundtrip conversions may benefit from sub-second timestamps, but
>> personally I think negative timestamps are more interesting and of
>> practical use.
>
> You mean, as in times before the Unix epoch 1970-01-01T00:00:
Junio C Hamano :
> Roundtrip conversions may benefit from sub-second timestamps, but
> personally I think negative timestamps are more interesting and of
> practical use.
You mean, as in times before the Unix epoch 1970-01-01T00:00:00Z?
Interesting. I hadn't thought of that. I've never seen
Jeff King writes:
> 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
Jeff King :
> Felipe suggested using git-notes to add the metadata, which I think is a
> reasonable first step. The git side of the code is already written, and
> the concept is nicely modularized away from the core of git. Nobody has
> to care about it but your importer, and anybody who wants to q
On Tue, Nov 27, 2012 at 10:47:00PM -0500, Eric S. Raymond wrote:
> Jeff King :
> > A much more compelling argument to me would be that you are doing some
> > bidirectional magic between git and svn, and you want to make make sure
> > that an svn->git->svn translation will result in the exact same
Jeff King :
> A much more compelling argument to me would be that you are doing some
> bidirectional magic between git and svn, and you want to make make sure
> that an svn->git->svn translation will result in the exact same bytes.
> Then the argument is still "because SVN has it", but at least it
On Tue, Nov 27, 2012 at 10:23:37PM -0500, Eric S. Raymond wrote:
> Jeff King :
> > But I really wonder if anybody actually cares about adding sub-second
> > timestamp support, or if it is merely "because SVN has it".
>
> There's actually one possible other reason to care. 1-second granularity
>
Jeff King :
> But I really wonder if anybody actually cares about adding sub-second
> timestamp support, or if it is merely "because SVN has it".
There's actually one possible other reason to care. 1-second granularity
isn't quite fine enough to guarantee that a (committer, timestamp)
pair is a
"Eric S. Raymond" writes:
> Junio C Hamano :
>> fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
>> the author and committer ident (i.e. the timestamp has to be
>> integral number of seconds since the epoch, not before it, nor
>> with fractional seconds).
>
> Is this architectura
> -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
> > wrote:
> > > On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond
> wrote:
> > >
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
> wrote:
> > On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond wrote:
> >> Shawn Pearce :
> >>> Well... if we added a fractional seconds to a commit, older versions
> >>> of Git wi
Felipe Contreras :
> % git cat-file -p HEAD
>
> You'll see exactly how git stores commits. Changing anything in there
> must be done carefully.
Oh, I've seen *that* before. Are you telling me the database
representation is actually textual?
--
http://www.catb.org/~esr/";>Eric S
On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras
wrote:
> On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond wrote:
>> Shawn Pearce :
>>> 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
On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond wrote:
> Shawn Pearce :
>> 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..
On Tue, 27 Nov 2012, Eric S. Raymond wrote:
Shawn Pearce :
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 da
Shawn Pearce :
> 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
ve
On Tue, Nov 27, 2012 at 3:04 PM, Eric S. Raymond wrote:
> Junio C Hamano :
>> fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
>> the author and committer ident (i.e. the timestamp has to be
>> integral number of seconds since the epoch, not before it, nor
>> with fractional secon
Junio C Hamano :
> fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
> the author and committer ident (i.e. the timestamp has to be
> integral number of seconds since the epoch, not before it, nor
> with fractional seconds).
Is this architecturally significant? It sounds like anot
Shawn Pearce writes:
> JGit would fortunately ignore a floating point timestamp specification
> if given in a commit, but I don't know about other Git
> implementations... like say git. :-)
fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
the author and committer ident (i.e. the
> -Original Message-
> From: Eric S. Raymond
> Sent: Tuesday, November 27, 2012 3:48 PM
>
> Because I do a lot of work on repository conversion tools, I've had
> to learn a lot of detail about ontological mismatches between
> version-control systems - especially places where you lose metad
On Tue, Nov 27, 2012 at 12:48 PM, Eric S. Raymond wrote:
> Because I do a lot of work on repository conversion tools, I've had
> to learn a lot of detail about ontological mismatches between
> version-control systems - especially places where you lose metadata
> moving between them.
>
> In general
37 matches
Mail list logo
