Max Bowsher wrote:
> On 02/09/10 14:40, Michael Haggerty wrote:
>> Robert Haas wrote:
>>> On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>>> What weirdness, exactly, are you discussing now? I've lost track of
>>>> which problem(s) are still unresolved.
>>> Lots of commits that look like this:
>>>
>>> commit c50da22b6050e0bdd5e2ef97541d91aa1d2e63fb
>>> Author: PostgreSQL Daemon <webmaster@postgresql.org>
>>> Date: Sat Dec 2 08:36:42 2006 +0000
>>>
>>> This commit was manufactured by cvs2svn to create branch 'REL8_2_STABLE'.
>>>
>>> Sprout from master 2006-12-02 08:36:41 UTC PostgreSQL Daemon
>>> <webmaster@postgresql.org> ''
>>> Delete:
>>> src/backend/parser/gram.c
>>> src/interfaces/ecpg/preproc/pgc.c
>>> src/interfaces/ecpg/preproc/preproc.c
>> I addressed that problem in this email:
>>
>> http://archives.postgresql.org/pgsql-hackers/2010-08/msg01819.php
>>
>> Summary: it is caused by a known weakness in cvs2svn's
>> branch-parent-choosing code that would be difficult to solve.
>>
>> But it just occurred to me--the script contrib/git-move-refs.py is
>> supposed to fix problems like this. Have you run this script against
>> your git repository? (Caveat: I am not very familiar with the script,
>> which was contributed by a user. Please check the results carefully and
>> let us know how it works for you.)
>
> Moving refs can't possibly splice out branch creation commits.
Max,
My understanding was that the problem is not that the branches are
created, but that they are created from a non-optimal starting point,
making it necessary for each of them to be doctored using a fixup
commit. Since the tree contents following the first branch commit is
identical to the tree contents on trunk one commit later, moving the
branch tags will give the same branch contents without the need for
branch fixup commits, and the old (branch-fixed) commits, no longer
being referenced, will be garbage collected at the next "git gc". Why
don't you think this will work?
Michael