Re: What's cooking in git.git (Jan 2021, #04; Sat, 16)

[Elijah Newren <newren@gmail.com>]

Hi,

On Thu, Jan 21, 2021 at 10:35 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
> > Hi Junio,
> >
> > On Sat, Jan 16, 2021 at 2:02 PM Junio C Hamano <gitster@pobox.com> wrote:
> >> * en/merge-ort-perf (2021-01-15) 4 commits
> >>  - merge-ort: begin performance work; instrument with trace2_region_* calls
> >>  - Merge branch 'en/ort-directory-rename' into en/merge-ort-perf
> >>  - Merge branch 'en/ort-conflict-handling' into en/merge-ort-perf
> >>  - Merge branch 'en/diffcore-rename' into en/merge-ort-perf
> >>  (this branch uses en/diffcore-rename, en/merge-ort-3, en/ort-conflict-handling and en/ort-directory-rename.)
> >
> > Any chance we could merge this down to next now?  In terms of pre-requisites:
> >   * you merged en/diffcore-rename and en/merge-ort-3 to next already
> > (and marked both as "Will merge to master")
> >   * you previously labelled en/ort-conflict-handling as "Will merge to
> > next" (and it was reviewed by Stolee[1])
> >   * en/ort-directory-rename has now been reviewed by Taylor[2]
> > Also, en/merge-ort-perf itself has also been reviewed by Taylor[3].
>
> This one is a bit unfortunate in that it is so small a change by
> itself, but sits on top of en/ort-directory-rename.
>
> Even though I wanted to merge the en/ort-directory-rename down to
> 'next' yesterday, it has just got updated and I had to rebase the
> ort-perf branch using the material from the old thread, so neither
> is in 'next' as of now.  That's the cost of building on top of too
> many things that are in flex X-<.  I'll see if I can find time today
> to give it the last read-over before mergint the ort-d-r in 'next'
> but I am not very optimistic right now.
>
> > But I'd like a stable commit identifier to place in the '??????????'
>
> Well, we'd all like a stable commit contents in the first place ;-)

Yeah, so...I'm about to make it even worse.  I'm feeling really
embarrassed, but I discovered a huge memory leak due to a section of
code that I for some reason thought was associated with later changes
and had been planning to submit later, but I discovered it should have
been submitted already (along with other series that have already
merged to master).  The memory leak makes a small but measurable
difference on the performance numbers, and since my subsequent series
repeatedly refer to that commit message and the performance numbers it
reports, it's kinda important to get it right.  So...

* I'm not touching en/ort-directory-rename; I still think it is ready
for merging to next.
* I'm about to resubmit en/merge-ort-perf, turning it into a three patch series.

Sorry for the headaches.