Fork of git SCM with my patches. http://git.kilabit.info/git/atom?h=v1.8.5.1 2013-12-03T19:16:56Z 2013-12-03T19:16:56Z Junio C Hamano gitster@pobox.com 2013-12-03T19:16:56Z urn:sha1:a155a5f075cdc09e584a58d68bdce0c80e6c4b5a Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-12-03T18:40:40Z Nick Townsend nick.townsend@mac.com 2013-11-25T23:31:09Z urn:sha1:2951add0e908f04fd63b48b8fcc138ae4dd66116 The usage sample of add_submodule_odb() function in the Submodules section expects non-zero return value for success, but the function actually reports success with zero. Helped-by: René Scharfe <l.s.r@web.de> Reviewed-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Nick Townsend <nick.townsend@mac.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-12-02T23:34:44Z Junio C Hamano gitster@pobox.com 2013-12-02T23:34:44Z urn:sha1:be38bee862d628e29043b3f680580ceb24a6ba1e 2013-12-02T23:33:30Z Junio C Hamano gitster@pobox.com 2013-12-02T23:33:30Z urn:sha1:2f93541d88fadd1ff5307d81c2c8921ee3eea058 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-12-02T21:48:06Z Junio C Hamano gitster@pobox.com 2013-12-02T21:31:55Z urn:sha1:ac1fbbda2013416b6c6a93d65c5dcf6662a60579 When submodule.$name.update is given as hint from the upstream in the .gitmodules file, we used to blindly copy it to .git/config, unless there already is a value defined for the submodule. However, there is no reason to expect that the update mode hinted by the upstream is available in the version of Git the user is using, and a really custom "!cmd" prepared by an upstream person running on Linux may not even be available to a user on Windows. It is simply irresponsible to copy the setting blindly and to attempt to use it during a later "submodule update" without validating it first. Just show the suggested value to the diagnostic output, and set the value to 'none' in the configuration, if it is not one of the ones that are known to be supported by this version of Git. Helped-by: Jens Lehmann <Jens.Lehmann@web.de> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-11-27T20:14:45Z Junio C Hamano gitster@pobox.com 2013-11-27T20:14:45Z urn:sha1:d2446dfd7f3b3f8948142cfb07a0270e2497d93f Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-11-27T20:13:29Z Junio C Hamano gitster@pobox.com 2013-11-27T20:13:29Z urn:sha1:4a3fc52d34adcc83e32fb23b003c15715ebce64a * maint: remote-hg: don't decode UTF-8 paths into Unicode objects 2013-11-27T20:09:50Z Richard Hansen rhansen@bbn.com 2013-11-18T04:12:42Z urn:sha1:5c1d2e8af99c1cf24a38fe830d96a4aedce30e2b The internal mercurial API expects ordinary 8-bit string objects, not Unicode string objects. With this change, the test-hg.sh unit tests pass again. Signed-off-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-11-25T16:20:02Z Junio C Hamano gitster@pobox.com 2013-11-25T16:20:02Z urn:sha1:c302941cd7670357bcd8209218e5f73c39e13d16 Unbreaks a recent breakage due to use of unquote-c-style. This may need to be cherry-picked down to 1.8.4.x series. * 'rh/remote-hg-bzr-updates' (early part): remote-hg: don't decode UTF-8 paths into Unicode objects 2013-11-20T19:27:26Z Junio C Hamano gitster@pobox.com 2013-11-20T19:18:25Z urn:sha1:5fd09df3937f54c5cfda4f1087f5d99433cce527 Signed-off-by: Junio C Hamano <gitster@pobox.com>