Re: [PATCHv3] refs.c: enable large transactions

From: Jeff King <peff@peff.net>
Date: Apr 24, 2015, 17:19 UTC
Message-ID: <20150424171953.GA30592@peff.net>
In-Reply-To: <CAGZ79kYGDOUgzKmQOLAXkYYb-HZJCw3Y=iSLXWHVXcQ0pAiDBw@mail.gmail.com>

On Fri, Apr 24, 2015 at 09:16:28AM -0700, Stefan Beller wrote:

Show 10 quoted lines

> I think it's a mistake to s/Could/could/g for all errors in the code base
> as it reduces the information provided in the error messages.
> Just 3 days ago ("Regular Rebase Failure"). I used different
> capitalization to get a better understanding where the error may be.
> 
> So if we throw away that information, we should add new information
> to make the spot of the error easily findable in the source.
> That's why I proposed the idea of the version,filename,linenumber
> as that is one of the strongest signals (most information in a short
> amount of text) I can imagine.

I do like that idea, and I think you could base it on the trace_printf implementation. Note that it requires variadic macros, but I think that's OK. Just like trace_printf, we can do the macro implementation when we support that feature, and people on older systems just won't get the extra file/line data.

I also assume we would not show this information by default, but only with GIT_TRACE_ERRORS or something like that.

I would love it if we could also get a stack trace for warnings and errors. Very often the line number of the error() call is not nearly as interesting as the line number of the _caller_. But doing that portably is rather hard. Maybe a better option would be to make it easier to convince git to dump core at the right moments (e.g., dump core when we hit die() rather than calling exit). And then you can run gdb on the core file, which gives you a backtrace and much more.

-Peff