Re: PostgreSQL Developer meeting minutes up

Aidan Van Dyk wrote:
> * Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> [090527 07:29]:
> 
>> OTOH, there's some value in staying with current GIT repository. In  
>> EnterpriseDB, we maintain all the Oracle-compatibility stuff in a GIT  
>> repository that's based on the PostgreSQL mirror. If PostgreSQL switches  
>> to a new GIT repository/mirror, I'll have to rebase all that, and I'm  
>> not sure how well that works with all the merges and stuff. I'm probably  
>> the one with most complex situation, but others who have  
>> work-in-progress patches in local repositories will face the same issue  
>> at a smaller scale.
> 
> But there are oodles of options in git available to handle a cutover
> like that:
> - grafts
> - filter-branch

Okay, your git-fu is stronger than mine, I had never heard of grafts 
before :-).

> - rebase (the new rebase toolset can even attempt to rebase a DAG onto an
>   existing DAG, not just linear patches))

That's interesting, I once tested git-rebase on the version I have 
installed on a similar scenario and it didn't handle merges. If it does 
now, that's great.

> But, if there is nothing wrong with the current repo (except that it
> doesn't have tags), than we can easily add tags to it...

Yep. There's not *that* many tags in the CVS repository, we could just 
add them manually.

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