Re: PostgreSQL Developer meeting minutes up
От | Robert Haas |
---|---|
Тема | Re: PostgreSQL Developer meeting minutes up |
Дата | |
Msg-id | 603c8f070906030717h267221c3uc7f0d971ae82b0b2@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PostgreSQL Developer meeting minutes up (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: PostgreSQL Developer meeting minutes up
|
Список | pgsql-hackers |
On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander <magnus@hagander.net> wrote: > Greg Stark wrote: >> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund <andres@anarazel.de> wrote: >>> "git log --no-merges" hides the actual merge commits if that is what you >>> want. >> >> Ooh! Life seems so much sweeter now! >> >> Given that we don't have to see them then I'm all for marking bug fix >> patches which were applied to multiple branches as merges. That seems >> like it would make it easier for tools like gitk or to show useful >> information analogous to the cvs2pcl info. > > Right, if it adds additional metadata that lets the tools do their magic > better, and it's still easy to filter out, I don't see a downside. > >> I'm not sure whether we should mark the old branches getting merges >> down or the new branches getting merged up. I suspect I'm missing >> something but I don't see any reason one is better than the other. > > If you go from older to newer, the automatic merge algorithms have a > better chance of doing something smart since they can track previous > changes. At least I think that's how it works. > > But I think for most of the changes it wouldn't make a huge difference, > though - manual merging would be needed anyway. In practice, isn't it more likely that you would develop the change on the newest branch and then try to back-port it? However you do the import, you're going to want to do subsequent things the same way. ...Robert
В списке pgsql-hackers по дате отправления: