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

2015-04-24 Thread Stefan Beller
On Fri, Apr 24, 2015 at 11:12 AM, Jonathan Nieder jrnie...@gmail.com wrote: Stefan Beller wrote: I understood that you were talking about Could being capitalized. Though it's distributed 30/70 which hints to me we do not care in enough to explain the capitalized letters as slip-throughs on

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

2015-04-24 Thread Jonathan Nieder
Stefan Beller wrote: I understood that you were talking about Could being capitalized. Though it's distributed 30/70 which hints to me we do not care in enough to explain the capitalized letters as slip-throughs on review or such, but it looks like the authors choice to me. Lowercase, brief,

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

2015-04-24 Thread Jeff King
On Fri, Apr 24, 2015 at 09:23:16PM -0700, Junio C Hamano wrote: The proposals so far, including this one, assume that the bug reporter will first fail the operation with normal invocation of Git (e.g. without GIT_DIE_ABORT exported) and then retry the same operation in a different way (e.g.

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

2015-04-24 Thread Jeff King
On Sat, Apr 25, 2015 at 01:00:58AM -0400, Jeff King wrote: A better solution to what I proposed earlier is perhaps: git config alias.debug '!gdb --quiet \ -ex break exit \ -ex run \ -ex bt full \ -ex continue \ -ex quit \

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

2015-04-24 Thread Junio C Hamano
Jeff King p...@peff.net writes: So if anything, I think my inclination would be to make it easier to help people (and ourselves) get a backtrace from gdb. One can get a core for a running process with gcore, or trigger a coredump by killing with SIGABRT. But catching it at the exact moment

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

2015-04-24 Thread Stefan Beller
On Thu, Apr 23, 2015 at 6:37 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: On Thu, Apr 23, 2015 at 10:56 AM, Junio C Hamano gits...@pobox.com wrote: + int save_errno = errno; + error(Couldn't reopen %s, lock-lk-filename.buf);

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

2015-04-24 Thread Jeff King
On Fri, Apr 24, 2015 at 09:16:28AM -0700, Stefan Beller wrote: 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

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

2015-04-24 Thread Jeff King
On Fri, Apr 24, 2015 at 11:12:36AM -0700, Jonathan Nieder wrote: Actually, I wouldn't mind an environment variable that tells error() to include a backtrace if someone wants it. (See backtrace(3) for implementation hints if interested in doing that.) Thanks, I didn't know about backtrace(3),

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

2015-04-23 Thread Junio C Hamano
Stefan Beller sbel...@google.com writes: diff --git a/refs.c b/refs.c index 4f495bd..7ce7b97 100644 --- a/refs.c +++ b/refs.c @@ -3041,6 +3041,13 @@ static int write_ref_sha1(struct ref_lock *lock, errno = EINVAL; return -1; } + if (lock-lk-fd == -1

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

2015-04-23 Thread Junio C Hamano
Stefan Beller sbel...@google.com writes: On Thu, Apr 23, 2015 at 10:56 AM, Junio C Hamano gits...@pobox.com wrote: + int save_errno = errno; + error(Couldn't reopen %s, lock-lk-filename.buf); No need to change this line, but I noticed that we might want to do

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

2015-04-23 Thread Stefan Beller
On Thu, Apr 23, 2015 at 10:56 AM, Junio C Hamano gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: diff --git a/refs.c b/refs.c index 4f495bd..7ce7b97 100644 --- a/refs.c +++ b/refs.c @@ -3041,6 +3041,13 @@ static int write_ref_sha1(struct ref_lock *lock,

[PATCHv3] refs.c: enable large transactions

2015-04-22 Thread Stefan Beller
This is another attempt on enabling large transactions (large in terms of open file descriptors). We keep track of how many lock files are opened by the ref_transaction_commit function. When more than a reasonable amount of files is open, we close the file descriptors to make sure the transaction