git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/6] update-ref: Test handling large transactions properly

From
Jeff King <peff@peff.net>
Date
Jan 21, 2015, 23:34 UTC
Message-ID
<20150121233457.GA11115@peff.net>
In-Reply-To
<1421882625-916-2-git-send-email-sbeller@google.com>
On Wed, Jan 21, 2015 at 03:23:40PM -0800, Stefan Beller wrote:
Show 18 quoted lines
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>  t/t1400-update-ref.sh | 28 ++++++++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
> index 6805b9e..ea98b9b 100755
> --- a/t/t1400-update-ref.sh
> +++ b/t/t1400-update-ref.sh
> @@ -1065,4 +1065,32 @@ test_expect_success 'stdin -z delete refs works with packed and loose refs' '
>  	test_must_fail git rev-parse --verify -q $c
>  '
>  
> +run_with_limited_open_files () {
> +	(ulimit -n 32 && "$@")
> +}
> +
> +test_lazy_prereq ULIMIT 'run_with_limited_open_files true'

We already have a ULIMIT prereq in t7004 that does something similar but different. The two do not conflict as long as they are in separate scripts, but they would if one gets moved into test-lib.sh. Should we maybe give these more descriptive names? It is not just about "ulimit", but the individual limit option. I can imagine a platform where "ulimit -s" works, but "ulimit -n" does not (or the other way around).

I almost also suggested that the two "ulimit -s" instances share the same function and lazy prereq, but I think that's probably not a good idea. One cares about limiting the stack, and the other care about limiting the cmdline size. The latter _happens_ to be done using "ulimit -s". That works on Linux, but no clue about elsewhere. I could easily imagine a platform where there is some other way, and we add a run-time switch.

> +test_expect_failure ULIMIT 'large transaction creating branches does not burst open file limit' '
> +(
> +	for i in $(seq 33)
Use test_seq here, for portability.
> +test_expect_failure ULIMIT 'large transaction deleting branches does not burst open file limit' '
> +(
> +	for i in $(seq 33)
Ditto here.
The rest of the tests looked good to me.
-Peff
Previous: Stefan BellerNext: Stefan Beller
Message 3 of 18 in “[PATCHv1 0/6] Fix bug in large transactions”
  1. Stefan BellerJan 21, 2015
  2. 1/6 update-ref: Test handling large transactions properlyStefan Beller, Jan 21, 2015
  3. Jeff KingJan 21, 2015
  4. 2/6 refs.c: remove lock_fd from struct ref_lockStefan Beller, Jan 21, 2015
  5. 3/6 refs.c: replace write_str_in_full by write_in_fullStefan Beller, Jan 21, 2015
  6. Jeff KingJan 21, 2015
  7. Stefan BellerJan 21, 2015
  8. Jeff KingJan 21, 2015
  9. 4/6 refs.c: Have a write_in_full_to_lock_file wrapping write_in_fullStefan Beller, Jan 21, 2015
  10. Jeff KingJan 21, 2015
  11. 5/6 refs.c: write to a lock file only onceStefan Beller, Jan 21, 2015
  12. Jeff KingJan 21, 2015
  13. 6/6 refs.c: enable large transactionsStefan Beller, Jan 21, 2015
  14. Jeff KingJan 21, 2015
  15. Junio C HamanoJan 22, 2015
  16. Stefan BellerJan 22, 2015
  17. Junio C HamanoJan 22, 2015
  18. Stefan BellerJan 22, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.