On 6/3/09, Greg Stark <stark@enterprisedb.com> 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.
>
> 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.
>
> 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.
Although "mark Tom's back-branch fixes as merges" makes much more
sense than "mark new files as merges", it is quite a step up from
"do tags match official releases".
It seems to require noticeable development effort to get a importer
to a level it can do it. Will this be a requirement for import?
Or just a good thing to have? Also how to check if all such merges
are sensible?
And note that such effort will affect only old imported history,
it will not make easier to handle back-branch fixes in the future...
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?
--
marko