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 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64 $ make NO_OPENSSL=1 [...] $ nm git | grep _SHA1_ 000100173f00 t _blk_SHA1_Block 000100174e80 T _blk_SHA1_Final 00010018fbb0 s _blk_SHA1_Final.pad 000100173de0 T _blk_SHA1_Init 000100173e10 T _blk_SHA1_Update However, with OpenSSL available, it does use the CommonCrypto functions: $ make [...] $ nm git | grep _SHA1_ U _CC_SHA1_Final U _CC_SHA1_Init U _CC_SHA1_Update I would not expect the presence of NO_OPENSSL=1 to change the behavior here, since neither case actually makes use of the OpenSSL SHA1 functions. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 submodules will be re-fetched from the remote if I pass --recurse-submodules. Is there any way to do this offline? Reading through the documentation, it doesn't seem easy, but perhaps it is possible to do by recursing through the submodules manually. In Homebrew, we allow building packages directly from a project's source repository. Currently, the repositories are downloaded into a local cache, then checked out into a build directory using git checkout-index and git submodule foreach. However, some projects require access to the git repository to do things like compute a version string. We experimented with using GIT_DIR, but sometimes we are operating on multiple git repositories, and saving and restoring its value in the right places is tedious and error prone. Our current solution is to symlink the .git directory into the build directory, but I'd like to replace this manual checkout + symlink with something cleaner. I could just copy the entire repository from the cache into the build directory, but we deal with some fairly large repositories so I would prefer to be able to use git clone or git clone --shared. Thanks for any suggestions, Jack -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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/CommandLineTools/usr/bin/make -C ../../ GIT-VERSION-FILE make[1]: `GIT-VERSION-FILE' is up to date. make: `../../GIT-VERSION-FILE' is up to date. $ ls contrib/subtree/git-subtree ls: contrib/subtree/git-subtree: No such file or directory The change appears to be inadvertent. I bisected it to 8e2a5ccad11bc21eb72499133bc884024e299983 (contrib/subtree/Makefile: use GIT-VERSION-FILE). This was reproduced on OS X 10.9 with GNU make 3.81. -Jack -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] remote.pushdefault and branch.name.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.name.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 plain git push from master errors out because I haven't provided a refspec or configured push.default. This makes sense. However, if the order of the two in the file is reversed, then a plain git push pushes to the origin repository, even though I have set the pushremote for master to upstream. This appears to be a bug. I would expect the order that things are defined in the config file to have no effect on the behavior of git push. I have reproduced this using git 1.9.0 and 1.8.3.4. Thanks, Jack -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
