Re: Todays git migration results

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alex Hunsaker <badalex(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Todays git migration results
Date: 2010-08-16 20:33:43
Message-ID: 21185.1281990823@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alex Hunsaker <badalex(at)gmail(dot)com> writes:
> How exactly patches get applied into back branches? Has that been
> spelled out somewhere? There are a lot of ways to do it. For
> instance git.git seems to apply the patch to the earliest branch first
> and then merge it on up so that everything can share the same
> commit/hash. That looks like a royal PITA to me, and I assume the
> plan is to just cherry-pick commits back. As long as we use git
> cherry-pick -x, I agree with Magnus, it should be fairly easy to write
> a short script to do it. II'll even volunteer if the above is
> basically the only requirement :-).

There was discussion about that before, but I don't know whether we
really have a solution that will work comfortably. A couple of
comments:

* My practice has always been to develop a fix in HEAD first and then
work backwards. I'm going to resist any tool that tries to force me
to do it the other way. There are a couple of reasons for that: one,
I'm generally more familiar with HEAD, and two, I want HEAD to have the
cleanest solution. If you do an old branch first, you'll probably come
up with a solution that is good for that branch but could be improved
in newer ones, eg by using some subroutine or facility that doesn't
exist earlier. Forward-patching won't encourage you to find that.

* My experience is that a patch that has to go back more than one or two
branches is almost never exactly the same on each branch, even without
any of the non-trivial changes suggested above. We constantly do things
like rearrange the arguments of some function that's used everywhere.
So "patch" is definitely not smart enough to back-patch the fixes by
itself. Maybe git will be a lot smarter but I'm not expecting miracles.
Anything that is based on "same hash" is pretty much guaranteed to
not do what I need.

I'd be satisfied with a tool that merges commit reports if they have the
same log message and occur at approximately the same time, which is the
heuristic that cvs2cl uses.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-08-16 20:34:07 Re: Writeable CTEs Desgin Doc on Wiki
Previous Message Alex Hunsaker 2010-08-16 20:14:14 Re: Todays git migration results