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

Re: [PATCHv1 0/6] Fix bug in large transactions

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 22, 2015, 08:00 UTC
Message-ID
<xmqqsif3tfcf.fsf@gitster.dls.corp.google.com>
In-Reply-To
<20150121234659.GE11115@peff.net>
Jeff King <peff@peff.net> writes:
Show 20 quoted lines
> On Wed, Jan 21, 2015 at 03:23:39PM -0800, Stefan Beller wrote:
>
>> (reported as: git update-ref --stdin : too many open files, 2014-12-20)
>> 
>> First a test case is introduced to demonstrate the failure,
>> the patches 2-6 are little refactoring and the last patch 
>> fixes the bug and also marks the bugs as resolved in the
>> test suite.
>> 
>> Unfortunately this applies on top of origin/next.
>
> Saying "applies on next" is not very useful to Junio. He is not going to
> branch a topic straight from "next", as merging it to master would pull
> in all of the topics cooking in "next" (not to mention a bunch of merge
> commits which are generally never part of "master").
>
> Instead, figure out which topic in next you actually _need_ to build on,
> and then it can be branched from there. And if there is no such topic,
> then you should not be building on next, of course. :) But I think you
> know that part already.
All very true.

I consider anything new that appears late in the cycle, especially during deep in the pre-release freeze, less for me to apply but more for others to eyeball the preview of a series the submitter plans to work on once the next cycle starts, so basing on 'next' does not hurt too much. For interested others,

	git checkout origin/next^0
would be shorter to type than
	git checkout "origin/next^{/^Merge branch 'sb/atomic-push'}^2"
so... ;-)

But what is more troublesome is that neither this or updated v2 applies to 'next'.

Let me try to wiggle it in first.
Thanks.
Previous: Jeff KingNext: Stefan Beller
Message 15 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.