* 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
- rebase (the new rebase toolset can even attempt to rebase a DAG onto an existing DAG, not just linear patches))
So I'm whatever becomes the "official" git repo can simply be "grafted"
into your history, your your new development grafted on to the
"official" history...
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...
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
