On 6/2/09, Markus Wanner <mar...@bluegap.ch> wrote: > Quoting "Marko Kreen" <mark...@gmail.com>: > > And what silly side effects are you talking about? > > > > I'm talking about spurious file duplicates popping up after a rename and a > merge, see my example in this thread.
The example was not actual case from Postgres CVS history, but hypotetical situation without checking if it already works with GIT. > > Also note we don't > > use branches for feature developement but for major version maintenance. > > > > So? You think you are never going to merge? > > > > So how can single file appearing in 2 branches means merge of 2 trees? > > How can that be valid? > > > > I'm not sure what you are questioning here. > > I find it perfectly reasonable to build something on top of REL8_3_STABLE > and later on wanting to merge to REL8_4_STABLE. And I don't want to manually > merge my changes, just because of a rename in 8.4 and a bad decision during > the migration to git. > > (And no, I don't think any of the other git tools will help with this, due > to the academic-nitpick-reasons above). Merging between branches with GIT is fine workflow in the future. But we are currently discussing how to convert CVS history to GIT. My point is that we should avoid fake merges, to avoid obfuscating history. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
