Skip site navigation (1) Skip section navigation (2)

Re: git: uh-oh

From: Max Bowsher <maxb(at)f2s(dot)com>
To: Michael Haggerty <mhagger(at)alum(dot)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: git: uh-oh
Date: 2010-09-03 02:34:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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(at)alum(dot)mit(dot)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(at)postgresql(dot)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(at)postgresql(dot)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:
>>> 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/ 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.


In response to


pgsql-hackers by date

Next:From: Michael HaggertyDate: 2010-09-03 03:17:15
Subject: Re: git: uh-oh
Previous:From: Tom LaneDate: 2010-09-03 02:08:08
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group