Front page | perl.perl5.porters |
Postings from September 2011
Re: [perl #98204] Shared objects not destoryed
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
September 2, 2011 10:38
Subject:
Re: [perl #98204] Shared objects not destoryed
Message ID:
20110902173755.GD23881@plum.flirble.org
On Fri, Sep 02, 2011 at 01:20:30PM -0400, Alex Vandiver wrote:
> On Fri, 2011-09-02 at 11:01 +0100, Nicholas Clark wrote:
> > He doesn't have the graft that removes the mistaken merge?
> >
> > [I can't remember the details, I suspect you can.]
>
> The graft that I'm familiar with is:
>
> umgah ~/prog/perl/git (blead) $ cat .git/info/grafts
> 296f12bbbbaa06de9be9d09d3dcf8f4528898a49 434946e0cb7a32589ed92d18008aaa1d88515930
>
> This modifies the parents of 296f12b, which is a commit on maint-5.10,
> to remove its second parent, which mistakenly points into blead. I
> believe it's possible to do the equivalent of distributing graft files
> using "replace" refs, but I'm not familiar enough with them to suggest
> how.
This was the only commit that I could find when trying to grovel around in
the history. And as it's a merge on on the maint-5.10 branch [strictly,
a merge only in the history of the maint-5.10 head], not a merge of
maint-5.10 back into blead [ie, a merge reachable from blead which has
one parent which is a commit that originates from //depot/perl/maint-5.10]
it can't affect bisection on blead.
So I kept digging on blead. And couldn't find anything. But the actual
explanation is:
On Fri, Sep 02, 2011 at 08:31:37AM -0700, Father Chrysostomos via RT wrote:
> > That's odd; the commit you show is from the 5.10 maint branch; not
> > sure
> > how a bisect ended up there.
>
> Well, this is the ineluctable result of doing things late at night. :-)
>
> I did it on the maint branch, because I assumed it would be faster,
Good idea! :-)
> since there are fewer commits there. Then I proceeded to forget that I
> was on the maint branch.
Not such a good idea! :-(
I haven't usually been too worried about speed. I find I'm sufficiently
prone to making mistakes when trying to git bisect manually [typically,
getting the wrong one of 'good' or 'bad'], that it's much faster to figure
out how to automate the test, copy my previous shell script for building,
and let `git bisect run` take care of everything else. At which point, it
seems that it's approximately the same amount of time to bisect 10 years of
history as 2. All praise O(log n) algorithms.
[This does go wrong when the test case needs threads, and I forget that my
previous shell script usually was building without threads, and the threads
tests in question "pass" on an unthreaded build]
Nicholas Clark
Thread Previous
|
Thread Next