Back-dating commits--way back--for constitution.git

Back-dating commits--way back--for constitution.git

[Joel C. Salomon]

I'd figured to play with Git in an unusual way: to create a repository
for the U.S. Constitution where amendments are presented as patches.
E.g., instead of the First Amendment being placed at the end (as is
usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
 Proposed amendments get branches, which get merged in later.

But I'm trying to get the dates right, and I'm missing something.  For
example, I made the initial commit with the line

	$ git commit --author="The Philadelphia Convention <>" \
	 --date="Mon, 17 Sep 1787 12:00:00 EST"

but that's not actually setting the commit date to 1787.

Am I doing something wrong, or is Git (quite reasonably) unable to
accept commit dates that far in the past?

--Joel

Re: Back-dating commits--way back--for constitution.git

[Shawn O. Pearce]

"Joel C. Salomon" <joelcsalomon@gmail.com> wrote:
> I'd figured to play with Git in an unusual way: to create a repository
> for the U.S. Constitution where amendments are presented as patches.
> E.g., instead of the First Amendment being placed at the end (as is
> usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
>  Proposed amendments get branches, which get merged in later.
> 
> But I'm trying to get the dates right, and I'm missing something.  For
> example, I made the initial commit with the line
> 
> 	$ git commit --author="The Philadelphia Convention <>" \
> 	 --date="Mon, 17 Sep 1787 12:00:00 EST"
> 
> but that's not actually setting the commit date to 1787.
> 
> Am I doing something wrong, or is Git (quite reasonably) unable to
> accept commit dates that far in the past?

Its probably running into problems with time_t on your system being a
32 bit value, and thus having trouble going before some time in 1901.

-- 
Shawn.

Re: Back-dating commits--way back--for constitution.git

[Joel C. Salomon]

On Mon, Aug 2, 2010 at 2:34 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> "Joel C. Salomon" <joelcsalomon@gmail.com> wrote:
<snip>
>>       $ git commit --author="The Philadelphia Convention <>" \
>>        --date="Mon, 17 Sep 1787 12:00:00 EST"
>>
>> but that's not actually setting the commit date to 1787.
>>
>> Am I doing something wrong, or is Git (quite reasonably) unable to
>> accept commit dates that far in the past?
>
> Its probably running into problems with time_t on your system being a
> 32 bit value, and thus having trouble going before some time in 1901.

I was afraid of that.  Oh, well.

Thanks,
--Joel

Re: Back-dating commits--way back--for constitution.git

[Ævar Arnfjörð Bjarmason]

On Mon, Aug 2, 2010 at 18:32, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
> I'd figured to play with Git in an unusual way: to create a repository
> for the U.S. Constitution where amendments are presented as patches.
> E.g., instead of the First Amendment being placed at the end (as is
> usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
>  Proposed amendments get branches, which get merged in later.
>
> But I'm trying to get the dates right, and I'm missing something.  For
> example, I made the initial commit with the line

As noted by Shawn time_t doesn't like ancient commits. But as an aside
I'd like to ask where this project is being hosted. I've wanted to
play with importing law into Git, and it would be interesting to
follow this project.

There's some Icelandic law currently enacted that hasn't been changed
since the 1200s. Getting that into Git would be interesting.

Re: Back-dating commits--way back--for constitution.git

[Jakub Narebski]

"Joel C. Salomon" <joelcsalomon@gmail.com> writes:

> I'd figured to play with Git in an unusual way: to create a repository
> for the U.S. Constitution where amendments are presented as patches.
> E.g., instead of the First Amendment being placed at the end (as is
> usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
>  Proposed amendments get branches, which get merged in later.
> 
> But I'm trying to get the dates right, and I'm missing something.  For
> example, I made the initial commit with the line
> 
> 	$ git commit --author="The Philadelphia Convention <>" \
> 	 --date="Mon, 17 Sep 1787 12:00:00 EST"
> 
> but that's not actually setting the commit date to 1787.
> 
> Am I doing something wrong, or is Git (quite reasonably) unable to
> accept commit dates that far in the past?

Git encodes author and commit (and tagger) time using Unix epoch
(POSIX epoch) plus timezone.  As Shawn and Ævar wrote on 32-bit
systems time_t can cover a range of about 136 years in total around
January 1, 1970, which means that the maximum representable time on
32-bit system is 2038-01-19 (the year 2038 problem), but what is more
important to you is that minimum representable time is 1901-12-13.
1787 is too old for 32-bit time_t.

The headers inside commit (and tag) objects are stored in text form,
so they are not limited to 32-bit value.  You would have to use system
that has 64-bit time_t, or patch git.

64-bit time_t would be enough for everyone (sic!).

References:
-----------
http://en.wikipedia.org/wiki/Unix_epoch
-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Back-dating commits--way back--for constitution.git

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> The headers inside commit (and tag) objects are stored in text form,
> so they are not limited to 32-bit value.  You would have to use system
> that has 64-bit time_t, or patch git.

I thought the internal representation of our time was "unsigned long", no?
How can you represent anything before Unix epoch?

Re: Back-dating commits--way back--for constitution.git

[Jakub Narebski]

Dnia wtorek 3. sierpnia 2010 00:47, Junio C Hamano napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > The headers inside commit (and tag) objects are stored in text form,
> > so they are not limited to 32-bit value.  You would have to use system
> > that has 64-bit time_t, or patch git.
> 
> I thought the internal representation of our time was "unsigned long", no?
> How can you represent anything before Unix epoch?

time_t is signed long.  Besides, git uses textual representation, its
just a matter of putting minus sign.  We can always fall back to
low level git-hash-object.

I'm just not sure if 'git commit' can work with dates prior to Unix
epoch.  I guess that git has some sanity checks that flies in the face
of such ab)use of git.

Refrences:
==========
[1] time(p) manpage
[2] http://en.wikipedia.org/wiki/Unix_epoch#Representing_the_number
[3] http://en.wikipedia.org/wiki/Time_t

-- 
Jakub Narebski
Poland

Re: Back-dating commits--way back--for constitution.git

[Jakub Narebski]

Dnia wtorek 3. sierpnia 2010 09:39, Jakub Narebski napisał:
> Dnia wtorek 3. sierpnia 2010 00:47, Junio C Hamano napisał:
> > Jakub Narebski <jnareb@gmail.com> writes:
> > 
> > > The headers inside commit (and tag) objects are stored in text form,
> > > so they are not limited to 32-bit value.  You would have to use system
> > > that has 64-bit time_t, or patch git.
> > 
> > I thought the internal representation of our time was "unsigned long", no?
> > How can you represent anything before Unix epoch?
> 
> time_t is signed long.  Besides, git uses textual representation, its
> just a matter of putting minus sign.  We can always fall back to
> low level git-hash-object.

And it works:

  $ git show
  commit a5f4eaace56c6887846ea77725e1ac6827bb13b0
  Author: Jakub Narebski <jnareb@gmail.com>
  Date:   Fri May 31 18:24:20 1929 +0200
  
      git-hash-object

  $ git cat-file -p HEAD
  tree 953e0e451fdcb5c21a25ee7ef9faade5791b95ee
  parent 6a28c9c996d785b716559f57149a9b5c11fd83ff
  author Jakub Narebski <jnareb@gmail.com> -1280820940 +0200
  committer Jakub Narebski <jnareb@gmail.com> 1280820940 +0200
  
  git-hash-object

-- 
Jakub Narebski
Poland

Re: Back-dating commits--way back--for constitution.git

[Michael J Gruber]

Jakub Narebski venit, vidit, dixit 02.08.2010 23:48:
> "Joel C. Salomon" <joelcsalomon@gmail.com> writes:
> 
>> I'd figured to play with Git in an unusual way: to create a repository
>> for the U.S. Constitution where amendments are presented as patches.
>> E.g., instead of the First Amendment being placed at the end (as is
>> usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
>>  Proposed amendments get branches, which get merged in later.
>>
>> But I'm trying to get the dates right, and I'm missing something.  For
>> example, I made the initial commit with the line
>>
>> 	$ git commit --author="The Philadelphia Convention <>" \
>> 	 --date="Mon, 17 Sep 1787 12:00:00 EST"
>>
>> but that's not actually setting the commit date to 1787.
>>
>> Am I doing something wrong, or is Git (quite reasonably) unable to
>> accept commit dates that far in the past?
> 
> Git encodes author and commit (and tagger) time using Unix epoch
> (POSIX epoch) plus timezone.  As Shawn and Ævar wrote on 32-bit
> systems time_t can cover a range of about 136 years in total around
> January 1, 1970, which means that the maximum representable time on
> 32-bit system is 2038-01-19 (the year 2038 problem), but what is more
> important to you is that minimum representable time is 1901-12-13.
> 1787 is too old for 32-bit time_t.
> 
> The headers inside commit (and tag) objects are stored in text form,
> so they are not limited to 32-bit value.  You would have to use system
> that has 64-bit time_t, or patch git.

Hmm, sizeof(time_t) == 8 for my x86_64 Fedora, but committing ancient
times fails.

My ctime() happily converts negative numbers into dates before the epoch.

> 
> 64-bit time_t would be enough for everyone (sic!).
> 
> References:
> -----------
> http://en.wikipedia.org/wiki/Unix_epoch

Junio replied:
>I thought the internal representation of our time was "unsigned long", >no?
>How can you represent anything before Unix epoch?

We have a mix of time_t and unsigned long (not signed, not long long!),
and we have our own tm_to_time_t() in date.c which explicitly forbids
years before 1970. It seems we don't use standard ctime() and friends
because the standards is not so standard and want to be independent of
that, but sizeof(long) is still system dependent.

Removing the check in tm_to_time_t() by brute force let's me commit
ancient times, but the parser gets them wrong (either on input or on
output, I haven't checked), 1787 ends up output as 1899.

time_t is signed on most systems. Using unsigned long buys us a few
years as long as we don't go through any system routine nor conversion
to time_t. So maybe we should:

- check to make sure we use time_t and system routines only when getting
the current time
- use signed long long as our git_time_t (I think long is less system
dependent then long but I could be wrong)
- make our own algorithms work for the extended format

Michael

Re: Back-dating commits--way back--for constitution.git

[Joshua Juran]

On Aug 3, 2010, at 1:55 AM, Michael J Gruber wrote:

> Jakub Narebski venit, vidit, dixit 02.08.2010 23:48:
>
>> The headers inside commit (and tag) objects are stored in text form,
>> so they are not limited to 32-bit value.  You would have to use  
>> system
>> that has 64-bit time_t, or patch git.
>>
>> 64-bit time_t would be enough for everyone (sic!).
>

> time_t is signed on most systems. Using unsigned long buys us a few
> years as long as we don't go through any system routine nor conversion
> to time_t. So maybe we should:
>
> - check to make sure we use time_t and system routines only when  
> getting
> the current time
> - use signed long long as our git_time_t (I think long is less system
> dependent then long but I could be wrong)

Obviously you mean "I think long long is less system dependent than  
long".

Does any system exist where long long is not 64 bits?  In any case,  
you can future-proof it by spelling it "int64_t".  That symbol is not  
guaranteed to exist (nor is <stdint.h>), but neither is the long long  
type in the first place.

> - make our own algorithms work for the extended format

This would enable systems with 32-bit time_t to deal with pre-1901  
commit timestamps in Git.[1]  Hopefully such systems will become  
increasingly rare.

Josh

[1] Or post-2038 timestamps, but any use case for such is dubious.

Re: Back-dating commits--way back--for constitution.git

[Jakub Narebski]

On Tue, 3 Aug 2010, Michael J Gruber wrote:
> Jakub Narebski venit, vidit, dixit 02.08.2010 23:48:
>> "Joel C. Salomon" <joelcsalomon@gmail.com> writes:
 
>>> [...] I'm trying to get the dates right, and I'm missing something.  For
>>> example, I made the initial commit with the line
>>>
>>> 	$ git commit --author="The Philadelphia Convention <>" \
>>> 	 --date="Mon, 17 Sep 1787 12:00:00 EST"
>>>
>>> but that's not actually setting the commit date to 1787.
>>>
>>> Am I doing something wrong, or is Git (quite reasonably) unable to
>>> accept commit dates that far in the past?
>> 
>> Git encodes author and commit (and tagger) time using Unix epoch
>> (POSIX epoch) plus timezone.  As Shawn and Ævar wrote on 32-bit
>> systems time_t can cover a range of about 136 years in total around
>> January 1, 1970, which means that the maximum representable time on
>> 32-bit system is 2038-01-19 (the year 2038 problem), but what is more
>> important to you is that minimum representable time is 1901-12-13.
>> 1787 is too old for 32-bit time_t.
>> 
>> The headers inside commit (and tag) objects are stored in text form,
>> so they are not limited to 32-bit value.  You would have to use system
>> that has 64-bit time_t, or patch git.
> 
> Hmm, sizeof(time_t) == 8 for my x86_64 Fedora, but committing ancient
> times fails.

That's because git *porcelain* either does not use time_t consistently,
or has some sanity checks that are good heuristic for ordinary use (like
e.g. commit time not too far in past where git didn't even exists),
or both.

It is not a problem on lowest level, i.e. repository format and plumbing.
I was able to create a commit that had author time before Unix epoch 
using plumbing:


1. create an ordinary commit as a template (so I don't have to go down
   to the level of gitcore-tutorial:

  $ git commit -a
  [master 8ddcf60] foo
  1 files changed, 1 insertions(+), 0 deletions(-)

2. save commit object in a file, to be edited

  $ git cat-file -p HEAD > tmp.txt

3. edit tmp.txt, changing sign of author time

  $ [edit tmp.txt]
  $ cat tmp.txt
  tree 953e0e451fdcb5c21a25ee7ef9faade5791b95ee
  parent 6a28c9c996d785b716559f57149a9b5c11fd83ff
  author Jakub Narebski <jnareb@gmail.com> -12808209400 +0200
  committer Jakub Narebski <jnareb@gmail.com> 1280820940 +0200
  
  git-hash-object

4. replace just created commit by handcrafted one

  $ git reset --hard HEAD^
  $ git hash-object -t commit -w tmp.txt
  fa5e5a2b6f27f10ce920ca82ffef07ed3eb3f26f
  $ git update-ref -m 'commit: foo' refs/heads/master \
  fa5e5a2b6f27f10ce920ca82ffef07ed3eb3f26f

5. check that porcelain parses date correctly

  $ git show
  commit a5f4eaace56c6887846ea77725e1ac6827bb13b0
  Author: Jakub Narebski <jnareb@gmail.com>
  Date:   Fri May 31 18:24:20 1929 +0200
  
      git-hash-object


Though when I tried to create commit with authordate further in the past,
porcelain shown 1970 (Unix epoch) as a date, but my system has 32-bit
time_t.

> My ctime() happily converts negative numbers into dates before the epoch.

Try ./test-date in git sources...
 
> Junio replied:
>>
>> I thought the internal representation of our time was "unsigned long",>no?
>> How can you represent anything before Unix epoch?
> 
> We have a mix of time_t and unsigned long (not signed, not long long!),
> and we have our own tm_to_time_t() in date.c which explicitly forbids
> years before 1970. It seems we don't use standard ctime() and friends
> because the standards is not so standard and want to be independent of
> that, but sizeof(long) is still system dependent.
> 
> Removing the check in tm_to_time_t() by brute force let's me commit
> ancient times, but the parser gets them wrong (either on input or on
> output, I haven't checked), 1787 ends up output as 1899.

Hmmm...

-- 
Jakub Narebski
Poland

Re: Back-dating commits--way back--for constitution.git

[Jakub Narebski]

Jakub Narebski wrote:
> 3. edit tmp.txt, changing sign of author time
> 
>   $ [edit tmp.txt]
>   $ cat tmp.txt
>   tree 953e0e451fdcb5c21a25ee7ef9faade5791b95ee
>   parent 6a28c9c996d785b716559f57149a9b5c11fd83ff
>   author Jakub Narebski <jnareb@gmail.com> -12808209400 +0200

Errr... wrong file copy'n'pasted.  It was

    author Jakub Narebski <jnareb@gmail.com> -1280820940 +0200

>   committer Jakub Narebski <jnareb@gmail.com> 1280820940 +0200

-- 
Jakub Narebski
Poland

Re: Back-dating commits--way back--for constitution.git

[Jeff King]

On Tue, Aug 03, 2010 at 02:32:06AM -0700, Joshua Juran wrote:

> >- use signed long long as our git_time_t (I think long is less system
> >dependent then long but I could be wrong)
> 
> Obviously you mean "I think long long is less system dependent than
> long".
> 
> Does any system exist where long long is not 64 bits?  In any case,
> you can future-proof it by spelling it "int64_t".  That symbol is not
> guaranteed to exist (nor is <stdint.h>), but neither is the long long
> type in the first place.

C99 specifies that "short" and "int" be at least 16 bits, that "long" be
at least 32 bits, and that "long long" be at least 64 bits. See section
5.2.4.2.1.

-Peff

Re: Back-dating commits--way back--for constitution.git

[Jeff King]

On Tue, Aug 03, 2010 at 12:02:52PM +0200, Jakub Narebski wrote:

> > Hmm, sizeof(time_t) == 8 for my x86_64 Fedora, but committing ancient
> > times fails.
> 
> That's because git *porcelain* either does not use time_t consistently,
> or has some sanity checks that are good heuristic for ordinary use (like
> e.g. commit time not too far in past where git didn't even exists),
> or both.
> 
> It is not a problem on lowest level, i.e. repository format and plumbing.
> I was able to create a commit that had author time before Unix epoch 
> using plumbing:

I am not sure there isn't some unportability at the lowest level. We
freely interchange between time_t and unsigned long in the low-level
date code. It probably happens to work because casting the bits back and
forth between signed and unsigned types generally works, as long as you
end up with the type that you want. But it isn't necessarily portable,
and there can be subtle bugs. See, for example, my recent 9ba0f033.

-Peff

Re: Back-dating commits--way back--for constitution.git

[Jakub Narebski]

On Tue, 3 Aug 2010, Jeff King wrote:
> On Tue, Aug 03, 2010 at 12:02:52PM +0200, Jakub Narebski wrote:
> 
> > > Hmm, sizeof(time_t) == 8 for my x86_64 Fedora, but committing ancient
> > > times fails.
> > 
> > That's because git *porcelain* either does not use time_t consistently,
> > or has some sanity checks that are good heuristic for ordinary use (like
> > e.g. commit time not too far in past where git didn't even exists),
> > or both.
> > 
> > It is not a problem on lowest level, i.e. repository format and plumbing.
> > I was able to create a commit that had author time before Unix epoch 
> > using plumbing:
> 
> I am not sure there isn't some unportability at the lowest level. We
> freely interchange between time_t and unsigned long in the low-level
> date code. It probably happens to work because casting the bits back and
> forth between signed and unsigned types generally works, as long as you
> end up with the type that you want. But it isn't necessarily portable,
> and there can be subtle bugs. See, for example, my recent 9ba0f033.

Well, at least there is not a problem at lowest of low, i.e. repository
format level, thanks to the use of textual representation for epoch.

-- 
Jakub Narebski
Poland

Re: Back-dating commits--way back--for constitution.git

[Jeff King]

On Tue, Aug 03, 2010 at 03:19:09PM +0200, Jakub Narebski wrote:

> > I am not sure there isn't some unportability at the lowest level. We
> > freely interchange between time_t and unsigned long in the low-level
> > date code. It probably happens to work because casting the bits back and
> > forth between signed and unsigned types generally works, as long as you
> > end up with the type that you want. But it isn't necessarily portable,
> > and there can be subtle bugs. See, for example, my recent 9ba0f033.
> 
> Well, at least there is not a problem at lowest of low, i.e. repository
> format level, thanks to the use of textual representation for epoch.

Yes, the good news that this is purely a code problem. The data format
is fine. It would just take somebody going through the code and
switching all "unsigned long" to "long long" (or time_t, or even
"gittime_t" if we want to abstract it).

-Peff

Re: Back-dating commits--way back--for constitution.git

[Michael J Gruber]

Jeff King venit, vidit, dixit 03.08.2010 15:20:
> On Tue, Aug 03, 2010 at 03:19:09PM +0200, Jakub Narebski wrote:
> 
>>> I am not sure there isn't some unportability at the lowest level. We
>>> freely interchange between time_t and unsigned long in the low-level
>>> date code. It probably happens to work because casting the bits back and
>>> forth between signed and unsigned types generally works, as long as you
>>> end up with the type that you want. But it isn't necessarily portable,
>>> and there can be subtle bugs. See, for example, my recent 9ba0f033.
>>
>> Well, at least there is not a problem at lowest of low, i.e. repository
>> format level, thanks to the use of textual representation for epoch.
> 
> Yes, the good news that this is purely a code problem. The data format
> is fine. It would just take somebody going through the code and
> switching all "unsigned long" to "long long" (or time_t, or even
> "gittime_t" if we want to abstract it).

...and fixing the parser algorithm at least in tm_to_time_t()...

Michael

Re: Back-dating commits--way back--for constitution.git

[Jeff King]

On Tue, Aug 03, 2010 at 03:24:17PM +0200, Michael J Gruber wrote:

> > Yes, the good news that this is purely a code problem. The data format
> > is fine. It would just take somebody going through the code and
> > switching all "unsigned long" to "long long" (or time_t, or even
> > "gittime_t" if we want to abstract it).
> 
> ...and fixing the parser algorithm at least in tm_to_time_t()...

Yeah, I should have been more clear. It is _not_ just "sed s/unsigned
long/long long", but rather checking every change to make sure that you
aren't introducing new bugs, and that the code correctly handles signed
types. Which is why nobody has done it. ;)

-Peff

Re: Back-dating commits--way back--for constitution.git

[Joshua Juran]

On Aug 3, 2010, at 5:44 AM, Jeff King wrote:

> On Tue, Aug 03, 2010 at 02:32:06AM -0700, Joshua Juran wrote:
>
>>> - use signed long long as our git_time_t (I think long is less  
>>> system
>>> dependent then long but I could be wrong)
>>
>> Obviously you mean "I think long long is less system dependent than
>> long".
>>
>> Does any system exist where long long is not 64 bits?  In any case,
>> you can future-proof it by spelling it "int64_t".  That symbol is not
>> guaranteed to exist (nor is <stdint.h>), but neither is the long long
>> type in the first place.
>
> C99 specifies that "short" and "int" be at least 16 bits, that  
> "long" be
> at least 32 bits, and that "long long" be at least 64 bits. See  
> section
> 5.2.4.2.1.

Right, but there's no guarantee that long long won't be *larger* than  
64 bits.  Though maybe that wouldn't be a problem.

Josh

Re: Back-dating commits--way back--for constitution.git

[Jeff King]

On Tue, Aug 03, 2010 at 10:37:26AM -0700, Joshua Juran wrote:

> >>Does any system exist where long long is not 64 bits?  In any case,
> >>you can future-proof it by spelling it "int64_t".  That symbol is not
> >>guaranteed to exist (nor is <stdint.h>), but neither is the long long
> >>type in the first place.
> >
> >C99 specifies that "short" and "int" be at least 16 bits, that
> >"long" be
> >at least 32 bits, and that "long long" be at least 64 bits. See
> >section
> >5.2.4.2.1.
> 
> Right, but there's no guarantee that long long won't be *larger* than
> 64 bits.  Though maybe that wouldn't be a problem.

Ah, I took your statement to mean "at least". In this case, I don't
think it would be a problem (we could just represent more times).

-Peff

Re: Back-dating commits--way back--for constitution.git

[Joel C. Salomon]

On 08/02/2010 05:25 PM, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Aug 2, 2010 at 18:32, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
>> I'd figured to play with Git in an unusual way: to create a repository
>> for the U.S. Constitution where amendments are presented as patches.
>> E.g., instead of the First Amendment being placed at the end (as is
>> usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
>> Proposed amendments get branches, which get merged in later.
> 
> I'd like to ask where this project is being hosted. I've wanted to
> play with importing law into Git, and it would be interesting to
> follow this project.

It's local to my machine for now, especially since I can't (yet?) get
the dates right. Also, I'm rebasing as I tweak the TeX code.

Law-into-RCS has been on my mind since I learned out what RCSs are for.
 Read any bill that the US Congress passes: there's an intro, a whole
lot of boilerplate, and then:

SEC. 101. EXTENSION OF CHIP.

    Section 2104(a) (42 U.S.C. 1397dd(a)) is amended--
            (1) in paragraph (10), by striking ``and'' at the end;
            (2) by amending paragraph (11), by striking ``each of
        fiscal years 2008 and 2009'' and inserting ``fiscal year
        2008''; and
            (3) by adding at the end the following new paragraphs:
            ``(12) for fiscal year 2009, $10,562,000,000;
            ``(13) for fiscal year 2010, $12,520,000,000;
            ``(14) for fiscal year 2011, $13,459,000,000;
            ``(15) for fiscal year 2012, $14,982,000,000; and
            ``(16) for fiscal year 2013, for purposes of making 2 semi-
        annual allotments--
                    ``(A) $3,000,000,000 for the period beginning on
                October 1, 2012, and ending on March 31, 2013, and
                    ``(B) $3,000,000,000 for the period beginning on
                April 1, 2013, and ending on September 30, 2013.''.

SEC. 102. ALLOTMENTS FOR STATES AND TERRITORIES FOR FISCAL YEARS 2009
              THROUGH 2013.

    Section 2104 (42 U.S.C. 1397dd) is amended--
            (1) in subsection (b)(1), by striking ``subsection (d)''
        and inserting ``subsections (d) and (m)'';
            (2) in subsection (c)(1), by striking ``subsection (d)''
        and inserting ``subsections (d) and (m)(4)''; and
            (3) by adding at the end the following new subsection:
....

Sure looks like a patch series to me.

> There's some Icelandic law currently enacted that hasn't been changed
> since the 1200s. Getting that into Git would be interesting.

Extremely.

I'll put my Constitution project up on GitHub in a few days.  Just note
that I *will* rebase and publish.

--Joel

Re: Back-dating commits--way back--for constitution.git

[Ævar Arnfjörð Bjarmason]

On Wed, Aug 4, 2010 at 16:38, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
> On 08/02/2010 05:25 PM, Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Aug 2, 2010 at 18:32, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
>>> I'd figured to play with Git in an unusual way: to create a repository
>>> for the U.S. Constitution where amendments are presented as patches.
>>> E.g., instead of the First Amendment being placed at the end (as is
>>> usual) I'm putting it in Article 1, Section 9 (Limitations of Congress).
>>> Proposed amendments get branches, which get merged in later.
>>
>> I'd like to ask where this project is being hosted. I've wanted to
>> play with importing law into Git, and it would be interesting to
>> follow this project.
>
> It's local to my machine for now, especially since I can't (yet?) get
> the dates right. Also, I'm rebasing as I tweak the TeX code.
>
> Law-into-RCS has been on my mind since I learned out what RCSs are for.
>  Read any bill that the US Congress passes: there's an intro, a whole
> lot of boilerplate, and then:
>
> SEC. 101. EXTENSION OF CHIP.
>
>    Section 2104(a) (42 U.S.C. 1397dd(a)) is amended--
>            (1) in paragraph (10), by striking ``and'' at the end;
>            (2) by amending paragraph (11), by striking ``each of
>        fiscal years 2008 and 2009'' and inserting ``fiscal year
>        2008''; and
>            (3) by adding at the end the following new paragraphs:
>            ``(12) for fiscal year 2009, $10,562,000,000;
>            ``(13) for fiscal year 2010, $12,520,000,000;
>            ``(14) for fiscal year 2011, $13,459,000,000;
>            ``(15) for fiscal year 2012, $14,982,000,000; and
>            ``(16) for fiscal year 2013, for purposes of making 2 semi-
>        annual allotments--
>                    ``(A) $3,000,000,000 for the period beginning on
>                October 1, 2012, and ending on March 31, 2013, and
>                    ``(B) $3,000,000,000 for the period beginning on
>                April 1, 2013, and ending on September 30, 2013.''.
>
> SEC. 102. ALLOTMENTS FOR STATES AND TERRITORIES FOR FISCAL YEARS 2009
>              THROUGH 2013.
>
>    Section 2104 (42 U.S.C. 1397dd) is amended--
>            (1) in subsection (b)(1), by striking ``subsection (d)''
>        and inserting ``subsections (d) and (m)'';
>            (2) in subsection (c)(1), by striking ``subsection (d)''
>        and inserting ``subsections (d) and (m)(4)''; and
>            (3) by adding at the end the following new subsection:
> ....
>
> Sure looks like a patch series to me.

Yeah, I think every legal system has their own ad-hoc patch convention
like that. It can be really hard to figure it all out. Parsing that is
non-trivial, but being able to generate diffs based on that would be a
very valuable resource.

>> There's some Icelandic law currently enacted that hasn't been changed
>> since the 1200s. Getting that into Git would be interesting.
>
> Extremely.
>
> I'll put my Constitution project up on GitHub in a few days.  Just note
> that I *will* rebase and publish.

Great.

Re: Back-dating commits--way back--for constitution.git

[Joel C. Salomon]

On 08/04/2010 12:38 PM, Joel C. Salomon wrote:
> I'll put my Constitution project up on GitHub in a few days.  Just note
> that I *will* rebase and publish.

It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
 (No amendments yet.)

I'm curious to find out if folks with 64-bit time_t get the correct
author and commit times.

--Joel

Re: Back-dating commits--way back--for constitution.git

[Ævar Arnfjörð Bjarmason]

On Thu, Aug 5, 2010 at 21:37, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
> On 08/04/2010 12:38 PM, Joel C. Salomon wrote:
>> I'll put my Constitution project up on GitHub in a few days.  Just note
>> that I *will* rebase and publish.
>
> It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
>  (No amendments yet.)
>
> I'm curious to find out if folks with 64-bit time_t get the correct
> author and commit times.

On 32bit:

commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date:   Wed Dec 31 19:59:59 1969 -0400

On 64bit:

commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
Author: The Philadelphia Convention <>
Date:   Mon Sep 17 13:00:00 1787 -0400

It would be useful to turn that into a TODO test for Git.

Re: Back-dating commits--way back--for constitution.git

[Sverre Rabbelier]

Heya,

On Thu, Aug 5, 2010 at 16:58, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> On 32bit:
>
> commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
> Author: The Philadelphia Convention <>
> Date:   Wed Dec 31 19:59:59 1969 -0400
>
> On 64bit:
>
> commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
> Author: The Philadelphia Convention <>
> Date:   Mon Sep 17 13:00:00 1787 -0400
>
> It would be useful to turn that into a TODO test for Git.

That's bad, if we can't store a particular date we should do something
about it, not just silently underflow.

-- 
Cheers,

Sverre Rabbelier

Re: Back-dating commits--way back--for constitution.git

[Jakub Narebski]

Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Thu, Aug 5, 2010 at 16:58, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> > On 32bit:
> >
> > commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
> > Author: The Philadelphia Convention <>
> > Date:   Wed Dec 31 19:59:59 1969 -0400
> >
> > On 64bit:
> >
> > commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
> > Author: The Philadelphia Convention <>
> > Date:   Mon Sep 17 13:00:00 1787 -0400
> >
> > It would be useful to turn that into a TODO test for Git.
> 
> That's bad, if we can't store a particular date we should do something
> about it, not just silently underflow.

We can *store* it without problems, the problem is with
*interpretation* by porcelain (and some plumbing).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Back-dating commits--way back--for constitution.git

[Michael Witten]

On Fri, Aug 6, 2010 at 03:18, Jakub Narebski <jnareb@gmail.com> wrote:
> the problem is with *interpretation* by
> porcelain (and some plumbing).

The problem is that git was written with leaky abstractions.

Re: Back-dating commits--way back--for constitution.git

[Sverre Rabbelier]

Heya,

On Fri, Aug 6, 2010 at 03:18, Jakub Narebski <jnareb@gmail.com> wrote:
> We can *store* it without problems, the problem is with
> *interpretation* by porcelain (and some plumbing).

That's what I mean though, if the porcelain notices it's trying to
read in a date it can't interpret correctly it should warn the user of
this fact.

-- 
Cheers,

Sverre Rabbelier

Re: Back-dating commits--way back--for constitution.git

[Joel C. Salomon]

On Thu, Aug 5, 2010 at 5:58 PM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On Thu, Aug 5, 2010 at 21:37, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
>> It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
>>
>> I'm curious to find out if folks with 64-bit time_t get the correct
>> author and commit times.
>
> On 32bit:
>
> commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
> Author: The Philadelphia Convention <>
> Date:   Wed Dec 31 19:59:59 1969 -0400
>
> On 64bit:
>
> commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
> Author: The Philadelphia Convention <>
> Date:   Mon Sep 17 13:00:00 1787 -0400

Cool, it works!  (The 13:00 should have been 12:00, but there's some
DST weirdness at work.)

Can you check what git-fsck has to say about the repos, on 32- &
64-bit machines?

--Joel

Re: Back-dating commits--way back--for constitution.git

[Ævar Arnfjörð Bjarmason]

On Fri, Aug 6, 2010 at 15:18, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
> On Thu, Aug 5, 2010 at 5:58 PM, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> On Thu, Aug 5, 2010 at 21:37, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
>>> It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
>>>
>>> I'm curious to find out if folks with 64-bit time_t get the correct
>>> author and commit times.
>>
>> On 32bit:
>>
>> commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
>> Author: The Philadelphia Convention <>
>> Date:   Wed Dec 31 19:59:59 1969 -0400
>>
>> On 64bit:
>>
>> commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
>> Author: The Philadelphia Convention <>
>> Date:   Mon Sep 17 13:00:00 1787 -0400
>
> Cool, it works!  (The 13:00 should have been 12:00, but there's some
> DST weirdness at work.)
>
> Can you check what git-fsck has to say about the repos, on 32- &
> 64-bit machines?

32bit says:

    error in commit 826a4f7721fe1c3963a733ecbc5422f05925af5d: invalid
author/committer line

64 bit doesn't give any warning at all.

Re: Back-dating commits--way back--for constitution.git

[Joel C. Salomon]

On Fri, Aug 6, 2010 at 11:19 AM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On Fri, Aug 6, 2010 at 15:18, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
>> Can you check what git-fsck has to say about the repos, on 32- &
>> 64-bit machines?
>
> 32bit says:
>
>    error in commit 826a4f7721fe1c3963a733ecbc5422f05925af5d: invalid
> author/committer line
>
> 64 bit doesn't give any warning at all.

Meanwhile, on Fri, Aug 6, 2010 at 11:08 AM, Sverre Rabbelier
<srabbelier@gmail.com> wrote:
> On Fri, Aug 6, 2010 at 03:18, Jakub Narebski <jnareb@gmail.com> wrote:
>> We can *store* it without problems, the problem is with
>> *interpretation* by porcelain (and some plumbing).
>
> That's what I mean though, if the porcelain notices it's trying to
> read in a date it can't interpret correctly it should warn the user of
> this fact.

Seems the error can be checked for when you ask, but I'd rather not
have git complain every time I use constitution.git.

Aside: I generated the time stamps with
<http://github.com/schwern/y2038>,  which may be useful for
cross-platform y2038 fixes.

--Joel

Re: Back-dating commits--way back--for constitution.git

[Brandon Casey]

Ævar Arnfjörð Bjarmason wrote:
> On Fri, Aug 6, 2010 at 15:18, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
>> On Thu, Aug 5, 2010 at 5:58 PM, Ævar Arnfjörð Bjarmason
>> <avarab@gmail.com> wrote:
>>> On Thu, Aug 5, 2010 at 21:37, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
>>>> It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
>>>>
>>>> I'm curious to find out if folks with 64-bit time_t get the correct
>>>> author and commit times.
>>> On 32bit:
>>>
>>> commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
>>> Author: The Philadelphia Convention <>
>>> Date:   Wed Dec 31 19:59:59 1969 -0400
>>>
>>> On 64bit:
>>>
>>> commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
>>> Author: The Philadelphia Convention <>
>>> Date:   Mon Sep 17 13:00:00 1787 -0400
>> Cool, it works!  (The 13:00 should have been 12:00, but there's some
>> DST weirdness at work.)
>>
>> Can you check what git-fsck has to say about the repos, on 32- &
>> 64-bit machines?
> 
> 32bit says:
> 
>     error in commit 826a4f7721fe1c3963a733ecbc5422f05925af5d: invalid
> author/committer line
> 
> 64 bit doesn't give any warning at all.

I don't think you're using the latest git.

I get this on 64 bit:

   error in commit 826a4f7721fe1c3963a733ecbc5422f05925af5d: invalid author/committer line - bad date

This is triggered by the negative sign '-' in front of the time
field which is not one of 0123456789.  See fsck.c line 244.

-brandon

Re: Back-dating commits--way back--for constitution.git

[Brandon Casey]

Joel C. Salomon wrote:
> On Thu, Aug 5, 2010 at 5:58 PM, Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>> On Thu, Aug 5, 2010 at 21:37, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
>>> It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
>>>
>>> I'm curious to find out if folks with 64-bit time_t get the correct
>>> author and commit times.
>> On 32bit:
>>
>> commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
>> Author: The Philadelphia Convention <>
>> Date:   Wed Dec 31 19:59:59 1969 -0400
>>
>> On 64bit:
>>
>> commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
>> Author: The Philadelphia Convention <>
>> Date:   Mon Sep 17 13:00:00 1787 -0400
> 
> Cool, it works!  (The 13:00 should have been 12:00, but there's some
> DST weirdness at work.)

Something other than the fact that -0400 should be -0500?
Or are you talking about an issue with the software you are using to
create the dates?

-brandon

Re: Back-dating commits--way back--for constitution.git

[Ævar Arnfjörð Bjarmason]

On Fri, Aug 6, 2010 at 16:00, Brandon Casey
<brandon.casey.ctr@nrlssc.navy.mil> wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Aug 6, 2010 at 15:18, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
>>> On Thu, Aug 5, 2010 at 5:58 PM, Ævar Arnfjörð Bjarmason
>>> <avarab@gmail.com> wrote:
>>>> On Thu, Aug 5, 2010 at 21:37, Joel C. Salomon <joelcsalomon@gmail.com> wrote:
>>>>> It's up, at <http://github.com/jcsalomon/constitution>, with one commit.
>>>>>
>>>>> I'm curious to find out if folks with 64-bit time_t get the correct
>>>>> author and commit times.
>>>> On 32bit:
>>>>
>>>> commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
>>>> Author: The Philadelphia Convention <>
>>>> Date:   Wed Dec 31 19:59:59 1969 -0400
>>>>
>>>> On 64bit:
>>>>
>>>> commit 826a4f7721fe1c3963a733ecbc5422f05925af5d
>>>> Author: The Philadelphia Convention <>
>>>> Date:   Mon Sep 17 13:00:00 1787 -0400
>>> Cool, it works!  (The 13:00 should have been 12:00, but there's some
>>> DST weirdness at work.)
>>>
>>> Can you check what git-fsck has to say about the repos, on 32- &
>>> 64-bit machines?
>>
>> 32bit says:
>>
>>     error in commit 826a4f7721fe1c3963a733ecbc5422f05925af5d: invalid
>> author/committer line
>>
>> 64 bit doesn't give any warning at all.
>
> I don't think you're using the latest git.

Guilty as charged. It's a Debian 1.7.1 git.

> I get this on 64 bit:
>
>   error in commit 826a4f7721fe1c3963a733ecbc5422f05925af5d: invalid author/committer line - bad date
>
> This is triggered by the negative sign '-' in front of the time
> field which is not one of 0123456789.  See fsck.c line 244.
>
> -brandon
>

Re: Back-dating commits--way back--for constitution.git

[Joel C. Salomon]

On 08/06/2010 12:44 PM, Brandon Casey wrote:
> Joel C. Salomon wrote:
>> Cool, it works!  (The 13:00 should have been 12:00, but there's some
>> DST weirdness at work.)
> 
> Something other than the fact that -0400 should be -0500?

No, that's probably it; I'd overlooked the time-zone specifier.  Thanks.

--Joel

Re: Back-dating commits--way back--for constitution.git

[Joshua Juran]

On Aug 7, 2010, at 8:46 PM, Joel C. Salomon wrote:

> On 08/06/2010 12:44 PM, Brandon Casey wrote:
>> Joel C. Salomon wrote:
>>> Cool, it works!  (The 13:00 should have been 12:00, but there's some
>>> DST weirdness at work.)
>>
>> Something other than the fact that -0400 should be -0500?
>
> No, that's probably it; I'd overlooked the time-zone specifier.   
> Thanks.

Daylight Saving Time wasn't adopted in the US until 1918, so all  
Eastern times before then should be displayed as -500, regardless of  
the time of year.

http://en.wikipedia.org/wiki/Daylight_saving_time

Josh