Re: git: uh-oh

On 02/09/10 16:44, Michael Haggerty wrote:
> 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?

You can't move a branchpoint after there are commits on the branch. I'm
pretty certain there will be commits on the REL8_2_STABLE branch :-)

Also, IIUC, this isn't the "one commit later" version of the problem -
it's a case of, for a period of *years*, the RCS files for these three
files claim they exist on trunk but no branches branching off trunk
during this period.

I am exploring the option of setting the unwanted revisions of the files
to the dead state (removing them outright doesn't work, since they have
a branch from one of the revisions in question.)

I have a test conversion running (well, a test conversion to bzr,
because I like qbzr so much more than gitk) and will report back.

Max.