Max Bowsher wrote:
> On 02/09/10 16:44, Michael Haggerty wrote:
>> 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 :-)
Good point. In the case of git, the branchpoint for a branch with
commits could be moved using grafts and then baked in using "git
filter-branch". But you are right that this is beyond the abilities of
contrib/git-move-refs.py, harder to justify, and wouldn't help in the
current case given your next point.
> 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 didn't realize that the anomaly was so long-lived.
> 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.)
That sounds promising. If it doesn't work, perhaps manually changing
the timestamps on the trunk revisions to an earlier date would help
isolate the problem and allow the branches to sprout from the
post-delete revision...
Thanks for the explanation.
Michael