I had a look but could not come up with a simple solution for this. CC Shawn who knows smart-http really well. On Sun, Mar 18, 2012 at 6:37 PM, Ivan Todoroski <grnch_lists@xxxxxxx> wrote: > Ivan Todoroski <grnch_lists <at> gmx.net> writes: >> Now share this repo using the Smart HTTP transport (git-http-backend) and > then >> try cloning it in a different directory. This is what you would get: >> >> $ git clone http://localhost/.../too-many-refs/.git >> Cloning into 'too-many-refs'... >> fatal: cannot exec 'fetch-pack': Argument list too long >> >> [...] >> >> The solution is conceptually simple: if the list of refs results in a too > long >> command line, split the refs in batches and call fetch-pack multiple times > such >> that each call is under the cmdline limit: >> >> git fetch-pack --stateless-rpc --lock-pack ...<first batch of refs>... >> git fetch-pack --stateless-rpc --lock-pack ...<second batch of refs>... >> ... >> git fetch-pack --stateless-rpc --lock-pack ...<last batch of refs>... > > > 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. > > > -- > 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 -- Duy -- 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