Greg Stark wrote: > On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund <and...@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. > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
