Combining APPLE_COMMON_CRYPTO=1 and NO_OPENSSL=1 produces unexpected result

When compiling git on OS X (where APPLE_COMMON_CRYPTO=1 is the default) and specifying NO_OPENSSL=1, the resulting git uses the BLK_SHA1 implementation rather than the functions available in CommonCrypto. $ uname -a Darwin broadwell.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PD

local clone and submodules

Say I have a local repository with several submodules that point at remote repositories. All submodules are up-to-date. I want to clone everything to another location on disk, *without hitting the network to fetch the submodules*. Obviously a simple "git clone" will work for the superproject, but

Running make in contrib/subtree does not create executable

Running "make" in contrib/subtree no longer creates the git-subtree executable: $ git describe v2.1.0 $ make -C contrib/subtree /Library/Developer/CommandLineTools/usr/bin/make -C ../../ GIT-VERSION-FILE GIT_VERSION = 2.1.0 make[1]: `GIT-VERSION-FILE' is up to date. /Library/Developer/CommandLineT

[BUG] remote.pushdefault and branch..pushremote definition order

There seems to be a difference in the behavior of "git push" depending on whether remote.pushdefault is defined before or after branch..pushremote in .git/config. If remote.pushdefault is defined to be "origin", and later in the file, branch.master.pushremote is defined to be "upstream", then a pl