Re: Clone fails on a repo with too many heads/tags

Ivan Todoroski <grnch_lists <at> gmx.net> writes:

then 

long 

such 

BTW, I didn't want to sound like I am expecting or demanding a fix. If the experienced Git devs lack the time or inclination to work on this bug (understandable), I am certainly willing to try it myself. My C skills are a bit rusty and I'm not very familiar with the Git codebase, but I will do my best to follow Documentation/SubmittingPatches as well as the existing code structure.

I will need a few pointers to get me started in the right direction though...

1) Is splitting the cmdline in batches and executing fetch-pack multiple times 
the right approach? If you have another solution please suggest.

2) Should I add the test case for this bug to existing scripts like t/t5551-
http-fetch.sh and t/t5561-http-backend.sh, or should I create a new test script 
under t/ following their example? There will probably be only one test case for 
this bug, basically the script I pasted in the original email to reproduce it.

3) What would be the most portable way to get the cmdline length limit between 
POSIX and Windows? Would something like this be acceptable:

#ifder _WIN32
	int cmdline_limit = 32767;
#else
	int cmdline_limit = sysconf(_SC_ARG_MAX);
#endif

I couldn't actually find a Windows API to get the cmdline limit, but this blog post by one of the Windows people tells the value:

http://blogs.msdn.com/b/oldnewthing/archive/2003/12/10/56028.aspx

4) Should this problem be fixed only in remote-curl.c:fetch_git() or should it 
be solved more generally in run-command.c:start_command(), which is used by 
fetch_git() for the actual invocation?

If this is fixed only in remote-curl:fetch_git(), then the same logic would need to be open coded in any other such place that might be found. Are you aware of any other internal sub-commands that put all refs on the command line and could be susceptible to the same issue?

If it's fixed at a lower level in run-command.c:start_command(), the logic would become available to any other sub-command that needs it.

However, this would mean that struct child_process as well as struct rpc_state would need an additional field that would tell whether the command is safe to execute in multiple batches and how many of the arguments at the beginning of child_process.argv must be preserved on every invocation (the switches and such).

Something like child_process.split_after, which if non-zero would mean that start_command() is free to invoke the command multiple times when argv exceeds the cmdline limit, by grouping any arguments after argv[split_after] in smaller batches for each invocation.