Hi, Tom Lane wrote: > I think it's already been made crystal clear that the people who > actually do this work don't do it that way, and are uninterested in > allowing their tools to force them to do it that way.
That's well understood. > Patching from > HEAD back works better for us for a number of reasons, the main one > being that HEAD is the version of the code that's most "swapped into" > our awareness. Committing on the oldest back-branch first doesn't necessarily mean having to develop the patch there. > However, so long as we can have a separate working copy per branch, > I see no problem with preparing all the versions of a patch and then > committing them back-to-front. That's what I think as well. However, I bet git could help a lot with creating all the versions of a patch in the first place. You don't *need* to use that feature, but preserving the option could help. > What I'm not clear about is the > mechanics for doing that. If you create each of the patches individually, there's not much magic required from git. It should be trivial to commit those as merges. > Would someone explain exactly what the > steps should be to produce the nicest-looking git history? I fear the cherry-picking approach creates the "nicest-looking" history (especially to the CVS trained eye). 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
