From: Christian Couder <chriscool@tuxfamily.org>
Date: Sun, 11 Oct 2009 13:43:39 GMT
Subject: Re: combine git repo historically
Message-ID: <200910111543.39327.chriscool@tuxfamily.org>
In-Reply-To: <200910111507.06926.j.sixt@viscovery.net>

On Sunday 11 October 2009, Johannes Sixt wrote:
> On Sonntag, 11. Oktober 2009, Jakub Narebski wrote:
> > Christian Couder <chriscool@tuxfamily.org> writes:
> > > $ git checkout -b repo1-branch1 remote/repo1/branch1
> > > $ git checkout N -- .
> > > $ export GIT_AUTHOR_NAME=<author name of commit N>
> > > $ export GIT_AUTHOR_EMAIL=<author email of commit N>
> > > $ export GIT_AUTHOR_DATE=<date of commit N>
> > > $ git commit -a
>
> This would not preserver the committer, but in particular the committer
> date is rather important for history traversal. You really don't want to
> change it. I used a much more elaborate pipleine involving
> git-commit-tree because I
>
> did not think about this simple procedure:
> >  $ git cat-file commit N > COMMIT_N
> >[ $ edit COMMIT_N  ]
> >  $ git hash-object -t commit -w COMMIT_N
>
> Thanks for this tip, Jakub.
>
> Christian, one thing that worries me is that 'git cat-file commit foo'
> returns the replacement (bar) instead of the original (foo). Is it
> intended? 

Yes it is intended. "git replace" was designed so that the original objects 
are not replaced only when reachability traversal (prune, pack transfer and 
fsck) wants to read the commit. See:

http://article.gmane.org/gmane.comp.version-control.git/104776/

> There is no way to retrieve the original commit using plumbing 
> unless the replacement is removed. Am I right?

I think you are right, but a flag could be easily added to some commands to 
retreive original objects. Or you can remove the replacement, retrieve the 
object and then put back the replacement.

Best regards,
Christian.