Re: PostgreSQL Developer meeting minutes up - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: PostgreSQL Developer meeting minutes up
Date
Msg-id e51f66da0906020917m274debd5u3288d6d56b62daf7@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL Developer meeting minutes up  ("Markus Wanner" <markus@bluegap.ch>)
Responses Re: PostgreSQL Developer meeting minutes up  ("Markus Wanner" <markus@bluegap.ch>)
List pgsql-hackers
On 6/2/09, Markus Wanner <markus@bluegap.ch> wrote:
>  Quoting "Marko Kreen" <markokr@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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Managing multiple branches in git
Next
From: Ron Mayer
Date:
Subject: Re: PostgreSQL Developer meeting minutes up