On Wed, Jun 3, 2009 at 10:20 AM, Marko Kreen <markokr@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
