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
