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> ''
>>> 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/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.
> 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 Haggerty||Date: 2010-09-03 03:17:15|
|Subject: Re: git: uh-oh|
|Previous:||From: Tom Lane||Date: 2010-09-03 02:08:08|
|Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!) |