On Tue, Mar 1, 2011 at 2:05 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Here are the topics that have been cooking. Commits prefixed with '-' are > only in 'pu' while commits prefixed with '+' are in 'next'. > > I started draft release notes for 1.7.5 on 'master' branch. > > -------------------------------------------------- > [New Topics] > > * jc/diff-irreversible-delete (2011-02-28) 1 commit > - git diff -D: omit the preimage of deletes > > Just a POC. > > * jc/index-pack (2011-02-25) 5 commits > - index-pack --verify: read anomalous offsets from v2 idx file > - write_idx_file: need_large_offset() helper function > - index-pack: --verify > - write_idx_file: introduce a struct to hold idx customization options > - index-pack: group the delta-base array entries also by type > > Still a WIP. > > * mm/push-default-advice (2011-02-28) 2 commits > - push: better error messages for detached HEAD and "no destination" > - push: better error message when push.default = tracking > > There were some rewording discussion I didn't roll into this, not because > I had objections to, but because I was handling other topics. I expect > I'll see a reroll soonish so that we can merge this down soonish. > > * sp/maint-fd-limit (2011-02-28) 2 commits > - mingw: add minimum getrlimit() compatibility stub > - Limit file descriptors used by packs > > Erik, please check the made-up commit log message and sign it off. > Will merge to 'next' after that. Do you have any hint on how I can create a repo with more than 2048 packs so I can test that the patch works? It builds just fine, perhaps that's enough? I guess Shawn already tested the other part... The reason I'm a bit in doubt is the following comment (from MSDN): "Note This upper limit may be beyond what is supported by a particular Win32 platform and configuration." But searching a bit more, it seems that the rest of the world seems to think 2048 is the correct maximum. I especially take comfort in reading that mysql (who keep a lot of open files) had their OS_FILE_LIMIT define set to 2048, and it seemed to work (apart from the times they needed even more open files!). I also find that there's a registry key called "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERProcessHandleQuota", and this is probably what they mean to warn about. I think consulting that would be completely overkill, and probably not even practically possible (because the relationship between the maximum number of open files and the maximum used handles isn't trivial). There's also the added complication that _open_osfhandle also seems to be limited by this 2048 limit (see the third comment here: http://bugs.mysql.com/bug.php?id=24509). We use this function for pipes and sockets as well. This alone might be a reason to corner-case test the resulting binary on Windows properly. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html