Committing with past date?

Hi,

Can someone tell me how to make a git commit with a date other than the
current. I hope there is some easier way than changing the system
clock.. :)

I'm trying to port over old version history that I maintained manually
(tarballs and changelogs) into a git repository. 

Best regards,
Magnus

Magnus Hjorth [off-list ref] writes:

Can someone tell me how to make a git commit with a date other than the
current. I hope there is some easier way than changing the system
clock.. :)

See git(1), section "Environment Variables":
   git Commits
       GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE,
       GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_COMMITTER_DATE,
       EMAIL
              see git-commit-tree(1)

or you can use GIT_COMMITTER_IDENT, GIT_AUTHOR_IDENT.  See output
of "git var -l" to get form of it.
 

I'm trying to port over old version history that I maintained manually
(tarballs and changelogs) into a git repository. 

For that, I think it would be best to take a look at example
fast-import script: contrib/fast-import/import-tars.perl;
there is equivalent contrib/fast-import/import-zips.py if you
perfer either Pyhon over Perl, and/or zips over tarballs.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Thank you Jakub! 

Forgot to look in the main git manpage, and that variable wasn't
mentioned in the git-commit manpage or in any FAQ.. 

Now I have a more tricky question.

The first part of my application history (the stone age) was maintained
manually using tarballs, but the second part was maintained using CVS
(the dark ages).

I have successfully imported the CVS history using git-cvsimport, but
now I want to add these older revisions that were made with tarballs to
the same tree, before the CVS revisions. The last tarball and the first
CVS revision have identical content, and I would like to somehow "glue"
the histories together.

Can this be done? 

Best regards,
Magnus



On Sun, 2008-08-31 at 04:12 -0700, Jakub Narebski wrote:

Magnus Hjorth [off-list ref] writes:

quoted

Can someone tell me how to make a git commit with a date other than the
current. I hope there is some easier way than changing the system
clock.. :)

See git(1), section "Environment Variables":
   git Commits
       GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE,
       GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_COMMITTER_DATE,
       EMAIL
              see git-commit-tree(1)

or you can use GIT_COMMITTER_IDENT, GIT_AUTHOR_IDENT.  See output
of "git var -l" to get form of it.
 

quoted

I'm trying to port over old version history that I maintained manually
(tarballs and changelogs) into a git repository. 

For that, I think it would be best to take a look at example
fast-import script: contrib/fast-import/import-tars.perl;
there is equivalent contrib/fast-import/import-zips.py if you
perfer either Pyhon over Perl, and/or zips over tarballs.

On Mon, Sep 1, 2008 at 9:25 AM, Magnus Hjorth [off-list ref] wrote:

Thank you Jakub!

Forgot to look in the main git manpage, and that variable wasn't
mentioned in the git-commit manpage or in any FAQ..

Now I have a more tricky question.

The first part of my application history (the stone age) was maintained
manually using tarballs, but the second part was maintained using CVS
(the dark ages).

I have successfully imported the CVS history using git-cvsimport, but
now I want to add these older revisions that were made with tarballs to
the same tree, before the CVS revisions. The last tarball and the first
CVS revision have identical content, and I would like to somehow "glue"
the histories together.

Can this be done?

I think you want git filter-branh --parent-filter ...

On Mon, 1 Sep 2008, Magnus Hjorth wrote:

On Sun, 2008-08-31 at 04:12 -0700, Jakub Narebski wrote:

quoted

Magnus Hjorth [off-list ref] writes:

quoted

Can someone tell me how to make a git commit with a date other than the
current. I hope there is some easier way than changing the system
clock.. :)

See git(1), section "Environment Variables":
   git Commits
       GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE,
       GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, GIT_COMMITTER_DATE,
       EMAIL
              see git-commit-tree(1)

or you can use GIT_COMMITTER_IDENT, GIT_AUTHOR_IDENT.  See output
of "git var -l" to get form of it.
 

quoted

I'm trying to port over old version history that I maintained manually
(tarballs and changelogs) into a git repository. 

For that, I think it would be best to take a look at example
fast-import script: contrib/fast-import/import-tars.perl;
there is equivalent contrib/fast-import/import-zips.py if you
perfer either Pyhon over Perl, and/or zips over tarballs.

Thank you Jakub! 

Forgot to look in the main git manpage, and that variable wasn't
mentioned in the git-commit manpage or in any FAQ.. 

Using GIT_AUTHOR_DATE etc. is a bit hacky, so that is why it is not
mentioned in git-commit homepage, but only in git-commit-index(1)
plumbing homepage, and of course on git(1) which should include _all_
environment variables affecting git execution.

By the way, is there any reason _not_ to use import-tars.perl from
the contrib/fast-import in your case?
 

Now I have a more tricky question.

The first part of my application history (the stone age) was maintained
manually using tarballs, but the second part was maintained using CVS
(the dark ages).

I have successfully imported the CVS history using git-cvsimport, but
now I want to add these older revisions that were made with tarballs to
the same tree, before the CVS revisions. The last tarball and the first
CVS revision have identical content, and I would like to somehow "glue"
the histories together.

Can this be done? 

It can be done for example using grafts. Search git mailing list for
graftshistory (or something like that) script, which was used to join
using grafts git "current work" Linux repository (started from "scratch").
Then you can check in gitk if everything is all right. If you truly
require connected histories, and not being able to locally turn on
and off the historical repository, you can always use git-filter-branch
which (among others) can turn grafts into true commits.

Linux kernel repo has current work repository, and legacy BitKeeper
repository, which one can join together if needed using grafts file
(see Documentation/gitrepository-layout.txt 

-- 
Jakub Narebski
ShadeHawk on #git
Poland

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on Wsenet and in e-mail?

On Tue, 2008-09-02 at 02:31 +0200, Jakub Narebski wrote:

On Mon, 1 Sep 2008, Magnus Hjorth wrote:

quoted

On Sun, 2008-08-31 at 04:12 -0700, Jakub Narebski wrote:

quoted

Magnus Hjorth [off-list ref] writes:

quoted

quoted

quoted

I'm trying to port over old version history that I maintained manually
(tarballs and changelogs) into a git repository. 

For that, I think it would be best to take a look at example
fast-import script: contrib/fast-import/import-tars.perl;
there is equivalent contrib/fast-import/import-zips.py if you
perfer either Pyhon over Perl, and/or zips over tarballs.

By the way, is there any reason _not_ to use import-tars.perl from
the contrib/fast-import in your case?

Well, I was planning do a lot of manual cleanup of the files also
(splitting commits, removing auto-generated files etc), so importing the
tarballs would just be the first step. But I'll try it, it can still be
useful to get a starting point...

quoted

I have successfully imported the CVS history using git-cvsimport, but
now I want to add these older revisions that were made with tarballs to
the same tree, before the CVS revisions. The last tarball and the first
CVS revision have identical content, and I would like to somehow "glue"
the histories together.

Can this be done? 

It can be done for example using grafts. Search git mailing list for
graftshistory (or something like that) script, which was used to join
using grafts git "current work" Linux repository (started from "scratch").
Then you can check in gitk if everything is all right. If you truly
require connected histories, and not being able to locally turn on
and off the historical repository, you can always use git-filter-branch
which (among others) can turn grafts into true commits.

The grafts approach looks interesting.

I still need some way to create multiple unconnected trees in one repo.
Maybe the safest way to do that is to create a separate historic repo
first and then transfer the historic branch using git-bundle to my main
working repo.

Regards,
Magnus

For information, there is a similar thread there :
http://n2.nabble.com/Force-commit-date-td2240539.html
-- 
View this message in context: http://n2.nabble.com/Committing-with-past-date--tp795326p2261665.html
Sent from the git mailing list archive at Nabble.com.