Aidan Van Dyk wrote:
* Heikki Linnakangas <heikki.linnakan...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
