Re: Committing with past date?

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?