Re: git name-rev looks at refs/notes, refs/svn/map: stack overflow
- From
Sebastiaan Dammann <triadsebas@gmail.com>
- Date
- Nov 12, 2019, 18:33 UTC
- Message-ID
- <CAE7Eq9hEiVf1rMNdWx55_nQsz2gVv0N+s1KckK1evtmruqcHyA@mail.gmail.com>
- In-Reply-To
- <20191111140956.GJ4348@szeder.dev>
Is there anything I can do to help? I have real-life (though proprietary) repositories to test the fix on.
On Mon, 11 Nov 2019 at 15:09, SZEDER Gábor <szeder.dev@gmail.com> wrote:
Show 31 quoted lines
> > On Sun, Nov 10, 2019 at 11:21:49PM -0500, Jeff King wrote: > > On Sat, Nov 09, 2019 at 12:31:31PM +0100, Sebastiaan Dammann wrote: > > > All of that's obviously a workaround, though. The real issue is the > > stack exhaustion. > > > > > I hope to hear your view on this. Is this an (confirmed) issue with > > > git? Are there beside the workaround I mentioned, any other > > > workarounds? > > > > Yes, this is well known. It's covered in the test suite (unfortunately > > still failing, of course) since 31625b34c0 (t6120: test describe and > > name-rev with deep repos, 2017-09-07). > > > > There was a proposed fix recently in: > > > > https://public-inbox.org/git/20190919214712.7348-1-szeder.dev@gmail.com/ > > > > but it doesn't seem to have been picked up. I'm not sure what the > > current status is. > > It's getting along, being polished, clarified and fine-tuned ever so > slowly. > > E.g. it turned out that the performance penalty from eliminating the > recursion is basically entirely caused by using a 'commit-list' to > store interesting parents (the overhead of a malloc() on each insert > and a free() on each pop). Switching to a LIFO 'prio-queue' doesn't > cause any measurable slowdown. >