Johannes Sixt <j6t@xxxxxxxx> writes: > The patch does add a new runtime dependency on libcrypto.dll in my > environment. I would be surprised if it does not also with your modern > build tools. > > I haven't had time to compare test suite runtimes. > >> I'm open to the argument that it doesn't matter in practice for normal >> git users. But it's not _just_ scripting. It depends on the user's >> pattern of invoking git commands (and how expensive the symbol >> resolution is on their system). > > It can be argued that in normal interactive use, it is hard to notice > that another DLL is loaded. Don't forget, though, that on Windows it > is not only the pure time to resolve the entry points, but also that > typically virus scanners inspect every executable file that is loaded, > which adds another share of time. > > I'll use the patch for daily work for a while to see whether it hurts. Thanks. I need to ask an unrelated question at a bit higher level, though. I have been operating under the assumption that everybody on Windows who builds Git works off of Dscho's Git for Windows tree, and patches that are specific to Windows from Dscho's are sent to me via the list only after they have been in Git for Windows and proven to help Windows users in the wild. The consequence of these two assumptions is that I would feel safe to treat Windows specific changes that do not touch generic part of the codebase from Dscho just like updates from any other subsystem maintainers (any git-svn thing from Eric, any gitk thing from Paul, any p4 thing Luke and Lars are both happy with, etc.). You seem to be saying that the first of the two assumptions does not hold. Should I change my expectations while queuing Windows specific patches from Dscho?