Re: PostgreSQL Developer meeting minutes up

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