On Wed, Jun 3, 2009 at 10:20 AM, Marko Kreen <mark...@gmail.com> wrote: > Various scenarios with git cherry-pick and similar tools would still > result in duplicate commits, so we would need a git log post-processor > anyway if we want to somehow group them together for eg. weekly commit > summary. And such post-processor would work on old history too. > > Maybe that's better direction to work on, than to potentially risk in > messy history in GIT?
I think it is. cherry-picking seems like a much better way of back-patching than merging, so putting a lot of effort into making merges "work" doesn't seem like a good expenditure of effort. It seems pretty clear that searching through the histories of each branch for duplicate commit messages and producing a unified report is pretty straightforward if we assume that the commit messages are byte-for-byte identical (or even modulo whitespace changes). But I wonder if it would make more sense to include some kind of metadata in the commit message (or some other property of the commit? does git support that?) to make it not depend on that. I suppose Tom et. al. like the way they do it now, so maybe we should just stick with text comparison, but it seems a bit awkward to me. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
