Fredrik Gustafsson <iveqy@xxxxxxxxx> writes: > On Thu, May 31, 2012 at 10:49:41AM -0700, Junio C Hamano wrote: >> Having said that, in the longer term, I think the right direction to >> go is the opposite. It would be better to make "git-submodule.sh" >> work better with paths with funny characters in them, and one >> obvious approach is to read "ls-files -z" output with something >> capable of parsing NUL-terminated records, e.g. a Perl scriptlet. >> Adding a new shell loop like this patch only adds one place that >> needs to be fixed later when that happens, so I am not sure I like >> this patch. > > Is perl really a dependency that git wants? It depends on your definition of "want"; I'd say "if alternative is to lose things like functionality, performance, etc., we would rather live with it." It is one of the more widely available scripting languages whose scripts are more portable across platforms (sadly, we ought to be able to use sed and awk which are more available but we have seen portability issues with them); if we want to step outside of what can be done with POSIX shell scripts (e.g. handling NUL terminated stream) but are not ready to rewrite everything in C, I would say it is the least evil among others. So the short answer is yes. > Today only a few bit (often > non critical) are in perl. I thought the way was to get rid of those and > replace them with c? But your patch does not help us bring ourselves any closer to replace anything with C at all. > I'm very critical to dependencies when they are not needed. The key-phrase is "when they are not needed". If the patch were to replace it with awk, sed or shell *without* losing functionality, performance, readability, portability & maintainability, it would be giving us one less dependency without losing anything. It may not be replacing everything with C, but at least it would not be going backwards. On the other hand, if the patch were to replace Perl scriptlet with ruby or python, that would be adding unnecessary extra dependencies, as we do not have anything written in them in the core. To such a patch, we can confidently say "It adds unnecessary dependency without value" and reject it. -- 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