Re: moving development branch activity to new git repo

On 21/09/10 18:28, Kevin Grittner wrote:
> I just went to do my usual merge from the git version of HEAD (at
> git://git.postgresql.org/git/postgresql.git), and it seemed to be
> doing an awful lot of work to prepare to attempt the merge.  That
> leads me to think that the newly converted git, or a copy of it, is
> now at that location, which is cool.  But I have concerns about what
> to do with my development branch off the old one.
>
> I'm afraid that in spite of several attempts, I don't yet properly
> have my head around the git approach, and fear that I'll muck things
> up without a little direction; and I'd be surprised if I'm the only
> one in this position.
>
> Can someone give advice, preferably in the form of a "recipe", for
> how to set up a new repo here based on the newly converted repo, and
> merge the work from my branch (with all the related history) into a
> branch off the new repo?

Some ideas:

A) Generate a patch in the old repo, and apply it to the new one. 
Simple, but you lose the history.

B) git rebase. First "git fetch" the new upstream repository into your 
local repository, and use git rebase to apply all the commits in your 
private branch over the new upstream branch. You will likely get some 
conflicts and will need to resolve them by hand, but if you're lucky 
it's not a lot of work.

C) Git grafts. I just tested this method for our internal EDB 
repository, and seems to work pretty well. You will need one line in 
your .git/info/grafts file for each merge commit with upstream that you 
have made. On each line you have 1. commitid of the merge commit 2. 
commitid of the old PostgreSQL commit that was merged 3. commitid of the 
corresponding PostgreSQL commit in the new repository. This lets you 
continue working on your repository as you used to, merging and all, but 
git diff will show that all the $PostgreSQL$ are different from the new 
upstream repository.

I'd suggest that you just do A) and keep the old repository around for 
reference.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com