On Mon, 1 Sep 2008, Magnus Hjorth wrote: > On Sun, 2008-08-31 at 04:12 -0700, Jakub Narebski wrote: > > Magnus Hjorth <magnus.hjorth@xxxxxxx> 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. > 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
