From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Greg Stark <stark(at)enterprisedb(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Markus Wanner <markus(at)bluegap(dot)ch>, Marko Kreen <markokr(at)gmail(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, 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-03 14:13:16 |
Message-ID: | 4A2684FC.2070006@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark wrote:
> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund <andres(at)anarazel(dot)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.
> Given that Tom's been intentionally marking the commits with identical
> commit messages we ought to be able to find *all* of them and mark
> them properly. That would be way better than only finding patches that
> are absolutely identical.
Just to be clear, not just Tom. All committers. I was told to do that
right after my first backpatch which *didn't* do it :-)
So it's an established project practice. That has other advantages as
well, of course..
> 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.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-06-03 14:17:06 | Re: PostgreSQL Developer meeting minutes up |
Previous Message | Greg Stark | 2009-06-03 14:01:18 | Re: PostgreSQL Developer meeting minutes up |