Hi, Quoting "Marko Kreen" <mark...@gmail.com>:
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.
As pointed out by others, it doesn't make sense to merge (all commits since the last merge) from HEAD to the back branches. You'd have to cherry-pick only the commits which actually have to get back patched.
The "new branches getting merged up" could work. That is, applying the fix to the oldest back-branch which requires the fix first and then merge it to all newer ones, including HEAD. However, that would require some rethinking: instead of creating bugfix-patches for HEAD, then manually adjust patches for back-branches and then group committing, you'd have to create a bugfix-patch for the oldest branch first, commit that and then merge that to the newer branches.
I consider merging a cleaner and simpler operation than cherry-picking, because merging allows the VCS to keep track of what needs to be propagated, while with cherry-picking, you'd have to keep track of that manually (or with the help of other tools).
An example for that is the very same unability to properly track renames when cherry-picking, just like what I explained for the CVS conversion.
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?
If that's how you'd like to have the CVS repository represented in git (which I'd support as well), I'd give it a try. With all of the work I've done for mtn cvs_import I certainly have the necessary experience in CVS conversion and with the cvs2svn algorithm itself.
And note that such effort will affect only old imported history, it will not make easier to handle back-branch fixes in the future...
Hm.. depends, if you want to merge from older branches to newer ones, instead of cherry-picking, it would certainly help to get the history clean.
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.
I think we should decide on either using merges or using duplicate commits we try to link somehow. But then, we should IMO use that scheme for the conversion as well as later on, so as not to get a messy history, as you put it.
Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
