From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
---|---|
To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
Cc: | Markus Wanner <markus(at)bluegap(dot)ch>, Marko Kreen <markokr(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL Developer meeting minutes up |
Date: | 2009-06-02 16:27:02 |
Message-ID: | 4A2552D6.101@cheapcomplexdevices.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aidan Van Dyk wrote:
> * Markus Wanner <markus(at)bluegap(dot)ch> [090602 10:23]:
>> As mentioned before, I'd personally favor *all* of the back-ports to
>> actually be merges of some sort, because that's what they effectively
>> are. However, that also bring up the question of how we are going to do
>> back-patches in the future with git.
>
> Well, if people get comfortable with it, I expect that "backports" don't
> happenen.. Bugs are fixed where they happen, and "merged" forward into
> all affected "later development" based on the bugged area.
I imagine the closest thing to existing practices would be that people
would to use "git-cherry-pick -x -n" to backport only the commits they
wanted from the current branch into the back branches.
AFAICT, this doesn't record a merge in the GIT history, but looks a lot
like the linear history from CVS - with the exception that the comment
added by "-x" explicitly refers to the exact commit from the main branch.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-06-02 16:28:04 | Re: Managing multiple branches in git |
Previous Message | Dave Page | 2009-06-02 16:23:51 | Re: Managing multiple branches in git |