Skip to main content

Browse the archive

swh:1:snp:bb8853bfef8fcf2b1d37fd6404912c7606c98e48
sort by:
Revision Author Date Message Commit Date
8e87cbc Junio C Hamano 16 March 2017, 20:56:41 UTC Merge branch 'js/travis-32bit-linux' into maint Add 32-bit Linux variant to the set of platforms to be tested with Travis CI. * js/travis-32bit-linux: Travis: also test on 32-bit Linux 16 March 2017, 20:56:42 UTC
890d765 Junio C Hamano 16 March 2017, 20:56:41 UTC Merge branch 'jh/mingw-openssl-sha1' into maint Windows port wants to use OpenSSL's implementation of SHA-1 routines, so let them. * jh/mingw-openssl-sha1: mingw: use OpenSSL's SHA-1 routines 16 March 2017, 20:56:41 UTC
d880bfd Junio C Hamano 16 March 2017, 20:56:41 UTC Merge branch 'jk/http-auth' into maint Reduce authentication round-trip over HTTP when the server supports just a single authentication method. * jk/http-auth: http: add an "auto" mode for http.emptyauth http: restrict auth methods to what the server advertises 16 March 2017, 20:56:41 UTC
f207548 Jeff King 16 March 2017, 14:27:20 UTC index-pack: make pointer-alias fallbacks safer The final() function accepts a NULL value for certain parameters, and falls back to writing into a reusable "name" buffer, and then either: 1. For "keep_name", requiring all uses to do "keep_name ? keep_name : name.buf". This is awkward, and it's easy to accidentally look at the maybe-NULL keep_name. 2. For "final_index_name" and "final_pack_name", aliasing those pointers to the "name" buffer. This is easier to use, but the aliased pointers become invalid after the buffer is reused (this isn't a bug now, but it's a potential pitfall). One way to make this safer would be to introduce an extra pointer to do the aliasing, and have its lifetime match the validity of the "name" buffer. But it's still easy to accidentally use the wrong name (i.e., to use "final_pack_name" instead of the aliased pointer). Instead, let's use three separate buffers that will remain valid through the function. That makes it safe to alias the pointers and use them consistently. The extra allocations shouldn't matter, as this function is not performance sensitive. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2017, 18:33:43 UTC
ba47a30 Jeff King 16 March 2017, 14:27:15 UTC replace snprintf with odb_pack_name() In several places we write the name of the pack filename into a fixed-size buffer using snprintf(), but do not check the return value. As a result, a very long object directory could cause us to quietly truncate the pack filename (potentially leading to a corrupted repository, as a newly written packfile could be missing its .pack extension). We can use odb_pack_name() to do this with a strbuf (and shorten the code, as well). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2017, 18:26:18 UTC
eaeefc3 Jeff King 16 March 2017, 14:27:12 UTC odb_pack_keep(): stop generating keepfile name The odb_pack_keep() function generates the name of a .keep file and opens it. This has two problems: 1. It requires a fixed-size buffer to create the filename and doesn't notice when the result is truncated. 2. Of the two callers, one sometimes wants to open a filename it already has, which makes things awkward (it has to do so manually, and skips the leading-directory creation). Instead, let's have odb_pack_keep() just open the file. Generating the name isn't hard, and a future patch will switch callers over to odb_pack_name() anyway. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2017, 18:17:00 UTC
1cec8c6 Jeff King 16 March 2017, 14:27:06 UTC sha1_file.c: make pack-name helper globally accessible We provide sha1_pack_name() and sha1_pack_index_name(), but the more generic form (which takes its own strbuf and an arbitrary extension) is only used to implement the other two. Let's make it available, but clean up a few things: 1. Name it odb_pack_name(), as the original sha1_get_pack_name() is long but not all that descriptive. 2. Switch the strbuf argument to the beginning, so that it matches similar path-building functions like git_path_buf(). 3. Clean up the out-dated docstring and move it to the public declaration. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2017, 18:05:17 UTC
82c9d66 Jeff King 16 March 2017, 14:27:00 UTC move odb_* declarations out of git-compat-util.h These functions were originally conceived as wrapper functions similar to xmkstemp(). They were later moved by 463db9b10 (wrapper: move odb_* to environment.c, 2010-11-06). The more appropriate place for a declaration is in cache.h. While we're at it, let's add some basic docstrings. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2017, 18:04:34 UTC
ffddfc6 Jeff King 15 March 2017, 20:08:02 UTC rev-parse: simplify parsing of ref options All of these options do the same thing "--foo" iterates over the "foo" refs, and "--foo=<glob>" does the same with a glob. We can factor this into its own function to avoid repeating ourselves. There are two subtleties to note: - the original called for_each_branch_ref(), etc, in the non-glob case. Now we will call for_each_ref_in("refs/heads/") which is exactly what for_each_branch_ref() did under the hood. - for --glob, we'll call for_each_glob_ref_in() with a NULL "prefix" argument. Which is exactly what for_each_glob_ref() was doing already. So both cases should behave identically, and it seems reasonable to assume that this will remain the same. The functions we are calling now are the more-generic ones, and the ones we are dropping are just convenience wrappers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 March 2017, 21:02:36 UTC
9d16ca6 Jeff King 15 March 2017, 20:06:53 UTC rev-parse: add helper for parsing "--foo/--foo=" We can't just use a bare skip_prefix() for these cases, because we need to match both the "--foo" form and the "--foo=<value>" form (and tell the difference between the two in the caller). We can wrap this in a simple helper which has two obvious callsites, and will gain some more in the next patch. Note that the error output for abbrev-ref changes slightly, as we don't keep our original "arg" pointer. However, the new output should hopefully be more clear: [before] fatal: unknown mode for --abbrev-ref=foo [after] fatal: unknown mode for --abbrev-ref: foo Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 March 2017, 21:01:51 UTC
ef87cc7 Jeff King 15 March 2017, 20:05:36 UTC rev-parse: use skip_prefix when parsing options Using skip_prefix lets us avoid manually-counted offsets into the argument string. This patch converts the simple and obvious cases. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 March 2017, 21:00:28 UTC
5ea3048 Stefan Beller 14 March 2017, 22:14:40 UTC submodule-config: correct error reporting for invalid ignore value As 'var' contains the whole value we get error messages that repeat the section and key currently: warning: Invalid parameter 'true' for config option 'submodule.submodule.plugins/hooks.ignore.ignore' Fix this by only giving the section name in the warning. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 March 2017, 18:26:08 UTC
b9e2bc5 Michael J Gruber 14 March 2017, 16:02:02 UTC git-status: make porcelain more robust git status provides a porcelain mode for porcelain writers with a supposedly stable (plumbing) interface. 7a76c28ff2 ("status: disable translation when --porcelain is used", 2014-03-20) made sure that ahead/behind info is not translated (i.e. is stable). Make sure that the remaining two strings (initial commit, detached head) are stable, too. These changes are for the v1 porcelain interface. While we do have a perfectly stable v2 porcelain interface now, some tools (such as powerline-gitstatus) are written against v1 and profit from fixing v1 without any changes on their side. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 14 March 2017, 20:15:18 UTC
d61434a Jeff King 13 March 2017, 14:04:45 UTC http-walker: fix buffer underflow processing remote alternates If we parse a remote alternates (or http-alternates), we expect relative lines like: ../../foo.git/objects which we convert into "$URL/../foo.git/" (and then use that as a base for fetching more objects). But if the remote feeds us nonsense like just: ../ we will try to blindly strip the last 7 characters, assuming they contain the string "objects". Since we don't _have_ 7 characters at all, this results in feeding a small negative value to strbuf_add(), which converts it to a size_t, resulting in a big positive value. This should consistently fail (since we can't generall allocate the max size_t minus 7 bytes), so there shouldn't be any security implications. Let's fix this by using strbuf_strip_suffix() to drop the characters we want. If they're not present, we'll ignore the alternate (in theory we could use it as-is, but the rest of the http-walker code unconditionally tacks "objects/" back on, so it is it not prepared to handle such a case). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 13 March 2017, 17:20:29 UTC
dfa3ad3 René Scharfe 10 March 2017, 00:12:59 UTC blame: move blame_entry duplication to add_blame_entry() All callers of add_blame_entry() allocate and copy the second argument. Let the function do it for them, reducing code duplication. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 12 March 2017, 05:28:22 UTC
bd4d9d9 Jeff King 25 February 2017, 09:37:30 UTC t/interop: add test of old clients against modern git-daemon This test just checks that old clients can clone and fetch from a newer git-daemon. The opposite should also be true, but it's hard to test ancient versions of git-daemon because they lack basic options like "--listen". Note that we have to make a slight tweak to the lib-git-daemon helper from the regular tests, so that it starts the daemon with our correct git.a version. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 March 2017, 22:30:25 UTC
3d89361 Jeff King 25 February 2017, 09:37:07 UTC t: add an interoperability test harness The current test suite is good at letting you test a particular version of Git. But it's not very good at letting you test _two_ versions and seeing how they interact (e.g., one cloning from the other). This commit adds a test harness that will build two arbitrary versions of git and make it easy to call them from inside your tests. See the README and the example script for details. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 10 March 2017, 22:30:25 UTC
ce83ead Johannes Schindelin 08 March 2017, 15:43:40 UTC real_pathdup(): fix callsites that wanted it to die on error In 4ac9006f832 (real_path: have callers use real_pathdup and strbuf_realpath, 2016-12-12), we changed the xstrdup(real_path()) pattern to use real_pathdup() directly. The problem with this change is that real_path() calls strbuf_realpath() with die_on_error = 1 while real_pathdup() calls it with die_on_error = 0. Meaning that in cases where real_path() causes Git to die() with an error message, real_pathdup() is silent and returns NULL instead. The callers, however, are ill-prepared for that change, as they expect the return value to be non-NULL (and otherwise the function died with an appropriate error message). Fix this by extending real_pathdup()'s signature to accept the die_on_error flag and simply pass it through to strbuf_realpath(), and then adjust all callers after a careful audit whether they would handle NULLs well. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 March 2017, 22:38:41 UTC
aac3eaa Johannes Schindelin 08 March 2017, 15:43:34 UTC t1501: demonstrate NULL pointer access with invalid GIT_WORK_TREE When GIT_WORK_TREE does not specify a valid path, we should error out, instead of crashing. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 March 2017, 22:38:22 UTC
d1a13d3 Jeff King 07 March 2017, 13:39:48 UTC send-pack: report signal death of pack-objects If our pack-objects sub-process dies of a signal, then it likely didn't have a chance to write anything useful to stderr. The user may be left scratching their head why the push failed. Let's detect this situation and write something to stderr. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 March 2017, 22:58:36 UTC
ba69f92 Jeff King 07 March 2017, 13:38:51 UTC send-pack: read "unpack" status even on pack-objects failure If the local pack-objects of a push fails, we'll tell the user about it. But one likely cause is that the remote index-pack stopped reading for some reason (because it didn't like our input, or encountered another error). In that case we'd expect the remote to report more details to us via the "unpack ..." status line. However, the current code just hangs up completely, and the user never sees it. Instead, let's call receive_unpack_status(), which will complain on stderr with whatever reason the remote told us. Note that if our pack-objects fails because the connection was severed or the remote just crashed entirely, then our packet_read_line() call may fail with "the remote end hung up unexpectedly". That's OK. It's a more accurate description than what we get now (which is just "some refs failed to push"). This should be safe from any deadlocks. At the point we make this call we'll have closed the writing end of the connection to the server (either by handing it off to a pack-objects which exited, explicitly in the stateless_rpc case, or by doing a half-duplex shutdown for a socket). So there should be no chance that the other side is waiting for the rest of our pack-objects input. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 March 2017, 22:57:39 UTC
40d05d0 Jeff King 07 March 2017, 13:37:36 UTC send-pack: improve unpack-status error messages When the remote tells us that the "unpack" step failed, we show an error message. However, unless you are familiar with the internals of send-pack and receive-pack, it was not clear that this represented an error on the remote side. Let's re-word to make that more obvious. Likewise, when we got an unexpected packet from the other end, we complained with a vague message but did not actually show the packet. Let's fix that. And finally, neither message was marked for translation. The message from the remote probably won't be translated, but there's no reason we can't do better for the local half. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 March 2017, 22:54:48 UTC
f7cd74d Jeff King 07 March 2017, 13:36:19 UTC send-pack: use skip_prefix for parsing unpack status This avoids repeating ourselves, and the use of magic numbers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 March 2017, 22:54:14 UTC
7c39df2 Jeff King 07 March 2017, 13:35:57 UTC send-pack: extract parsing of "unpack" response After sending the pack, we call receive_status() which gets both the "unpack" line and the ref status. Let's break these into two functions so we can call the first part independently. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 March 2017, 22:51:20 UTC
6cdad1f Jeff King 07 March 2017, 13:35:34 UTC receive-pack: fix deadlock when we cannot create tmpdir The err_fd descriptor passed to the unpack() function is intended to be handed off to the child index-pack, and our async muxer will read until it gets EOF. However, if we encounter an error before handing off the descriptor, we must manually close(err_fd). Otherwise we will be waiting for our muxer to finish, while the muxer is waiting for EOF on err_fd. We fixed an identical deadlock already in 49ecfa13f (receive-pack: close sideband fd on early pack errors, 2013-04-19). But since then, the function grew a new early-return in 722ff7f87 (receive-pack: quarantine objects until pre-receive accepts, 2016-10-03), when we fail to create a temporary directory. This return needs the same treatment. Reported-by: Horst Schirmeier <horst@schirmeier.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 07 March 2017, 22:51:03 UTC
3255e51 Jeff King 05 March 2017, 11:46:38 UTC ewah: fix eword_t/uint64_t confusion The ewah subsystem typedefs eword_t to be uint64_t, but some code uses a bare uint64_t. This isn't a bug now, but it's a potential maintenance problem if the definition of eword_t ever changes. Let's use the correct type. Note that we can't use COPY_ARRAY() here because the source and destination point to objects of different sizes. For that reason we'll also skip the usual "sizeof(*dst)" and use the real type, which should make it more clear that there's something tricky going on. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 March 2017, 20:03:40 UTC
07f546c Vegard Nossum 05 March 2017, 11:44:46 UTC line-log: use COPY_ARRAY to fix mis-sized memcpy This memcpy meant to get the sizeof a "struct range", not a "range_set", as the former is what our array holds. Rather than swap out the types, let's convert this site to COPY_ARRAY, which avoids the problem entirely (and confirms that the src and dst types match). Note for curiosity's sake that this bug doesn't trigger on I32LP64 systems, but does on ILP32 systems. The mistaken "struct range_set" has two ints and a pointer. That's 16 bytes on LP64, or 12 on ILP32. The correct "struct range" type has two longs, which is also 16 on LP64, but only 8 on ILP32. Likewise an IL32P64 system would experience the bug. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 March 2017, 20:01:02 UTC
88dedd5 Johannes Schindelin 05 March 2017, 18:25:19 UTC Travis: also test on 32-bit Linux When Git v2.9.1 was released, it had a bug that showed only on Windows and on 32-bit systems: our assumption that `unsigned long` can hold 64-bit values turned out to be wrong. This could have been caught earlier if we had a Continuous Testing set up that includes a build and test run on 32-bit Linux. Let's do this (and take care of the Windows build later). This patch asks Travis CI to install a Docker image with 32-bit libraries and then goes on to build and test Git using this 32-bit setup. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 March 2017, 19:19:09 UTC
5cae73d Eric Wong 04 March 2017, 01:50:16 UTC http: release strbuf on disabled alternates This likely has no real-world impact on memory usage, but it is cleaner for future readers. Fixes: abcbdc03895f ("http: respect protocol.*.allow=user for http-alternates") Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 March 2017, 18:52:57 UTC
de46138 Eric Wong 04 March 2017, 08:36:45 UTC http: inform about alternates-as-redirects behavior It is disconcerting for users to not notice the behavior change in handling alternates from commit cb4d2d35c4622ec2 ("http: treat http-alternates like redirects") Give the user a hint about the config option so they can see the URL and decide whether or not they want to enable http.followRedirects in their config. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 March 2017, 18:52:15 UTC
32da746 Devin J. Pohly 23 February 2017, 08:27:36 UTC p7000: add test for filter-branch with --prune-empty Signed-off-by: Devin J. Pohly <djpohly@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 March 2017, 20:43:37 UTC
a582a82 Devin J. Pohly 23 February 2017, 08:27:35 UTC filter-branch: fix --prune-empty on parentless commits Previously, the git_commit_non_empty_tree function would always pass any commit with no parents to git-commit-tree, regardless of whether the tree was nonempty. The new commit would then be recorded in the filter-branch revision map, and subsequent commits which leave the tree untouched would be correctly filtered. With this change, parentless commits with an empty tree are correctly pruned, and an empty file is recorded in the revision map, signifying that it was rewritten to "no commits." This works naturally with the parent mapping for subsequent commits. Signed-off-by: Devin J. Pohly <djpohly@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 March 2017, 20:43:37 UTC
4dacc8f Devin J. Pohly 23 February 2017, 08:27:34 UTC t7003: ensure --prune-empty removes entire branch when applicable Sanity check before changing the logic in git_commit_non_empty_tree. Signed-off-by: Devin J. Pohly <djpohly@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 March 2017, 20:43:37 UTC
377a354 Devin J. Pohly 23 February 2017, 08:27:33 UTC t7003: ensure --prune-empty can prune root commit New test to expose a bug in filter-branch whereby the root commit is never pruned, even though its tree is empty and --prune-empty is given. The setup isn't exactly pretty, but I couldn't think of a simpler way to create a parallel commit graph sans the first commit. Signed-off-by: Devin J. Pohly <djpohly@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 March 2017, 20:43:37 UTC
aaae0bf Allan Xavier 02 March 2017, 17:29:02 UTC line-log.c: prevent crash during union of too many ranges The existing implementation of range_set_union does not correctly reallocate memory, leading to a heap overflow when it attempts to union more than 24 separate line ranges. For struct range_set *out to grow correctly it must have out->nr set to the current size of the buffer when it is passed to range_set_grow. However, the existing implementation of range_set_union only updates out->nr at the end of the function, meaning that it is always zero before this. This results in range_set_grow never growing the buffer, as well as some of the union logic itself being incorrect as !out->nr is always true. The reason why 24 is the limit is that the first allocation of size 1 ends up allocating a buffer of size 24 (due to the call to alloc_nr in ALLOC_GROW). This goes some way to explain why this hasn't been caught before. Fix the problem by correctly updating out->nr after reallocating the range_set. As this results in out->nr containing the same value as the variable o, replace o with out->nr as well. Finally, add a new test to help prevent the problem reoccurring in the future. Thanks to Vegard Nossum for writing the test. Signed-off-by: Allan Xavier <allan.x.xavier@oracle.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 March 2017, 19:16:20 UTC
b8686c6 Sebastian Schuberth 03 March 2017, 10:57:46 UTC contrib: git-remote-{bzr,hg} placeholders don't need Python It does not make sense for these placeholder scripts to depend on Python just because the real scripts do. At the example of Git for Windows, we would not even be able to see those warnings as it does not ship with Python. So just use plain shell scripts instead. Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 March 2017, 19:09:34 UTC
28e1fb5 Jeff King 03 March 2017, 07:36:33 UTC t/perf: add fallback for pre-bin-wrappers versions of git It's tempting to say: ./run v1.0.0 HEAD to see how we've sped up Git over the years. Unfortunately, this doesn't quite work because versions of Git prior to v1.7.0 lack bin-wrappers, so our "run" script doesn't correctly put them in the PATH. Worse, it means we silently find whatever other "git" is in the PATH, and produce test results that have no bearing on what we asked for. Let's fallback to the main git directory when bin-wrappers isn't present. Many modern perf scripts won't run with such an antique version of Git, of course, but at least those failures are detected and reported (and you're free to write a limited perf script that works across many versions). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 March 2017, 18:55:27 UTC
83d4a40 Jeff King 03 March 2017, 07:14:03 UTC t/perf: use $MODERN_GIT for all repo-copying steps Since 1a0962dee (t/perf: fix regression in testing older versions of git, 2016-06-22), we point "$MODERN_GIT" to a copy of git that matches the t/perf script itself, and which can be used for tasks outside of the actual timings. This is needed because the setup done by perf scripts keeps moving forward in time, and may use features that the older versions of git we are testing do not have. That commit used $MODERN_GIT to fix a case where we relied on the relatively recent --git-path option. But if you go back further still, there are more problems. Since 7501b5921 (perf: make the tests work in worktrees, 2016-05-13), we use "git -C", but versions of git older than 44e1e4d67 (git: run in a directory given with -C option, 2013-09-09) don't know about "-C". So testing an old version of git with a new version of t/perf will fail the setup step. We can fix this by using $MODERN_GIT during the setup; there's no need to use the antique version, since it doesn't affect the timings. Likewise, we'll adjust the "init" invocation; antique versions of git called this "init-db". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 March 2017, 18:55:26 UTC
67f2825 Jonathan Tan 02 March 2017, 19:50:41 UTC t/perf: export variable used in other blocks In p0001, a variable was created in a test_expect_success block to be used in later test_perf blocks, but was not exported. This caused the variable to not appear in those blocks (this can be verified by writing 'test -n "$commit"' in those blocks), resulting in a slightly different invocation than what was intended. Export that variable. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 March 2017, 18:54:42 UTC
d56583d Matt McCutchen 22 February 2017, 16:05:57 UTC fetch-pack: add specific error for fetching an unadvertised object Enhance filter_refs (which decides whether a request for an unadvertised object should be sent to the server) to record a new match status on the "struct ref" when a request is not allowed, and have report_unmatched_refs check for this status and print a special error message, "Server does not allow request for unadvertised object". Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 19:12:53 UTC
e70a65c Matt McCutchen 22 February 2017, 16:02:15 UTC fetch_refs_via_pack: call report_unmatched_refs "git fetch" currently doesn't bother to check that it got all refs it sought, because the common case of requesting a nonexistent ref triggers a die() in get_fetch_map. However, there's at least one case that slipped through: "git fetch REMOTE SHA1" if the server doesn't allow requests for unadvertised objects. Make fetch_refs_via_pack (which is on the "git fetch" code path) call report_unmatched_refs so that we at least get an error message in that case. Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 19:12:53 UTC
e860d96 Matt McCutchen 22 February 2017, 16:01:22 UTC fetch-pack: move code to report unmatched refs to a function Prepare to reuse this code in transport.c for "git fetch". While we're here, internationalize the existing error message. Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 19:12:53 UTC
fd4692f Jeff King 02 March 2017, 08:23:18 UTC checkout: restrict @-expansions when finding branch When we parse "git checkout $NAME", we try to interpret $NAME as a local branch-name. If it is, then we point HEAD to that branch. Otherwise, we detach the HEAD at whatever commit $NAME points to. We do the interpretation by calling strbuf_branchname(), and then blindly sticking "refs/heads/" on the front. This leads to nonsense results when expansions like "@{upstream}" or "@" point to something besides a local branch. We end up with a local branch name like "refs/heads/origin/master" or "refs/heads/HEAD". Normally this has no user-visible effect because those branches don't exist, and so we fallback to feeding the result to get_sha1(), which resolves them correctly. But as the new test in t3204 shows, there are corner cases where the effect is observable, and we check out the wrong local branch rather than detaching to the correct one. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 19:05:04 UTC
7d5c960 Jeff King 02 March 2017, 08:23:14 UTC strbuf_check_ref_format(): expand only local branches This function asks strbuf_branchname() to expand any @-marks in the branchname, and then we blindly stick refs/heads/ in front of the result. This is obviously nonsense if the expansion is "HEAD" or a ref in refs/remotes/. The most obvious end-user effect is that creating or renaming a branch with an expansion may have confusing results (e.g., creating refs/heads/origin/master from "@{upstream}" when the operation should be disallowed). We can fix this by telling strbuf_branchname() that we are only interested in local expansions. Any unexpanded bits are then fed to check_ref_format(), which either disallows them (in the case of "@{upstream}") or lets them through ("refs/heads/@" is technically valid, if a bit silly). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 19:05:04 UTC
6b145e0 Jeff King 02 March 2017, 08:23:10 UTC branch: restrict @-expansions when deleting We use strbuf_branchname() to expand the branch name from the command line, so you can delete the branch given by @{-1}, for example. However, we allow other nonsense like "@", and we do not respect our "-r" flag (so we may end up deleting an oddly-named local ref instead of a remote one). We can fix this by passing the appropriate "allowed" flag to strbuf_branchname(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 19:05:04 UTC
a356e8e Jeff King 02 March 2017, 08:23:06 UTC t3204: test git-branch @-expansion corner cases git-branch feeds the branch names from the command line to strbuf_branchname(), but we do not yet tell that function which kinds of expansions should be allowed. Let's create a set of tests that cover both the allowed and disallowed cases. That shows off some breakages where we currently create or delete the wrong ref (and will make sure that we do not break any cases that _should_ be working when we do add more restrictions). Note that we check branch creation and deletion, but do not bother with renames. Those follow the same code path as creation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 19:05:04 UTC
0e9f62d Jeff King 02 March 2017, 08:23:01 UTC interpret_branch_name: allow callers to restrict expansions The interpret_branch_name() function converts names like @{-1} and @{upstream} into branch names. The expanded ref names are not fully qualified, and may be outside of the refs/heads/ namespace (e.g., "@" expands to "HEAD", and "@{upstream}" is likely to be in "refs/remotes/"). This is OK for callers like dwim_ref() which are primarily interested in resolving the resulting name, no matter where it is. But callers like "git branch" treat the result as a branch name in refs/heads/. When we expand to a ref outside that namespace, the results are very confusing (e.g., "git branch @" tries to create refs/heads/HEAD, which is nonsense). Callers can't know from the returned string how the expansion happened (e.g., did the user really ask for a branch named "HEAD", or did we do a bogus expansion?). One fix would be to return some out-parameters describing the types of expansion that occurred. This has the benefit that the caller can generate precise error messages ("I understood @{upstream} to mean origin/master, but that is a remote tracking branch, so you cannot create it as a local name"). However, out-parameters make the function interface somewhat cumbersome. Instead, let's do the opposite: let the caller tell us which elements to expand. That's easier to pass in, and none of the callers give more precise error messages than "@{upstream} isn't a valid branch name" anyway (which should be sufficient). The strbuf_branchname() function needs a similar parameter, as most of the callers access interpret_branch_name() through it. We can break the callers down into two groups: 1. Callers that are happy with any kind of ref in the result. We pass "0" here, so they continue to work without restrictions. This includes merge_name(), the reflog handling in add_pending_object_with_path(), and substitute_branch_name(). This last is what powers dwim_ref(). 2. Callers that have funny corner cases (mostly in git-branch and git-checkout). These need to make use of the new parameter, but I've left them as "0" in this patch, and will address them individually in follow-on patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 19:05:04 UTC
0705fe2 Jeff King 02 March 2017, 08:21:30 UTC strbuf_branchname: add docstring This function and its companion, strbuf_check_branch_ref(), did not have their purpose or semantics explained. Let's do so. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 19:05:04 UTC
311fc74 Jeff King 02 March 2017, 08:21:27 UTC strbuf_branchname: drop return value The return value from strbuf_branchname() is confusing and useless: it's 0 if the whole name was consumed by an @-mark, but otherwise is the length of the original name we fed. No callers actually look at the return value, so let's just get rid of it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 19:05:04 UTC
e322b60 Jeff King 02 March 2017, 08:21:23 UTC interpret_branch_name: move docstring to header file We generally put docstrings with function declarations, because it's the callers who need to know how the function works. Let's do so for interpret_branch_name(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 19:05:03 UTC
13228c3 Jeff King 27 February 2017, 09:25:40 UTC interpret_branch_name(): handle auto-namelen for @{-1} The interpret_branch_name() function takes a ptr/len pair for the name, but you can pass "0" for "namelen", which will cause it to check the length with strlen(). However, before we do that auto-namelen magic, we call interpret_nth_prior_checkout(), which gets fed the bogus "0". This was broken by 8cd4249c4 (interpret_branch_name: always respect "namelen" parameter, 2014-01-15). Though to be fair to that commit, it was broken in the _opposite_ direction before, where we would always treat "name" as a string even if a length was passed. You can see the bug with "git log -g @{-1}". That code path always passes "0", and without this patch it cannot figure out which branch's reflog to show. We can fix it by a small reordering of the code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 19:04:57 UTC
12426e1 Junio C Hamano 01 March 2017, 17:04:44 UTC diff: do not short-cut CHECK_SIZE_ONLY check in diff_populate_filespec() Callers of diff_populate_filespec() can choose to ask only for the size of the blob without grabbing the blob data, and the function, after running lstat() when the filespec points at a working tree file, returns by copying the value in size field of the stat structure into the size field of the filespec when this is the case. However, this short-cut cannot be taken if the contents from the path needs to go through convert_to_git(), whose resulting real blob data may be different from what is in the working tree file. As "git diff --quiet" compares the .size fields of filespec structures to skip content comparison, this bug manifests as a false "there are differences" for a file that needs eol conversion, for example. Reported-by: Mike Crowe <mac@mcrowe.com> Helped-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 18:48:06 UTC
c852bd5 Jeff King 02 March 2017, 09:48:22 UTC add--interactive: fix missing file prompt for patch mode with "-i" When invoked as "git add -i", each menu interactive menu option prompts the user to select a list of files. This includes the "patch" option, which gets the list before starting the hunk-selection loop. As "git add -p", it behaves differently, and jumps straight to the hunk selection loop. Since 0539d5e6d (i18n: add--interactive: mark patch prompt for translation, 2016-12-14), the "add -i" case mistakenly jumps to straight to the hunk-selection loop. Prior to that commit the distinction between the two cases was managed by the $patch_mode variable. That commit used $patch_mode for something else, and moved the old meaning to the "$cmd" variable. But it forgot to update the $patch_mode check inside patch_update_cmd() which controls the file-list behavior. The simplest fix would be to change that line to check $cmd. But while we're here, let's use a less obscure name for this flag: $patch_mode_only, a boolean which tells whether we are in full-interactive mode or only in patch-mode. Reported-by: Henrik Grubbström <grubba@grubba.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 02 March 2017, 18:10:38 UTC
bcd886d Eric Wong 01 March 2017, 22:22:04 UTC README: create HTTP/HTTPS links from URLs in Markdown Markdown supports automatic links by surrounding URLs with angle brackets, as documented in <https://daringfireball.net/projects/markdown/syntax#autolink> While we're at it, update URLs to avoid redirecting clients for git-scm.com (by using HTTPS) and public-inbox.org (by adding a trailing slash). Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 March 2017, 22:45:45 UTC
c650748 Ævar Arnfjörð Bjarmason 01 March 2017, 21:15:40 UTC gitweb tests: skip tests when we don't have Time::HiRes Change the gitweb tests to skip when we can't load the Time::HiRes module. Gitweb needs this module to work. It has been in perl core since v5.8, which is the oldest version we support. However CentOS (and perhaps some other distributions) carve it into its own non-core-perl package that's not installed along with /usr/bin/perl by default. Without this we'll hard fail the gitweb tests when trying to load the module. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 March 2017, 22:39:50 UTC
0b69e4f Ævar Arnfjörð Bjarmason 01 March 2017, 21:15:39 UTC gitweb tests: change confusing "skip_all" phrasing Change the phrasing so that instead of saying that the CGI module is unusable, we say that it's not available. This came up on the git mailing list in <4b34e3a0-3da7-d821-2a7f-9a420ac1d3f6@gmail.com> from Jakub Narębski. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 March 2017, 22:39:00 UTC
b2d593a Ramsay Jones 28 February 2017, 01:26:06 UTC wrapper.c: remove unused gitmkstemps() function The last call to the mkstemps() function was removed in commit 659488326 ("wrapper.c: delete dead function git_mkstemps()", 22-04-2016). In order to support platforms without mkstemps(), this functionality was provided, along with a Makefile build variable (NO_MKSTEMPS), by the gitmkstemps() function. Remove the dead code, along with the defunct build machinery. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 February 2017, 19:54:21 UTC
34de5e4 Ramsay Jones 28 February 2017, 01:24:10 UTC wrapper.c: remove unused git_mkstemp() function The last caller of git_mkstemp() was removed in commit 6fec0a89 ("verify_signed_buffer: use tempfile object", 16-06-2016). Since the introduction of the 'tempfile' APIs, along with git_mkstemp_mode, it is unlikely that new callers will materialize. Remove the dead code. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 February 2017, 19:54:14 UTC
8e27391 Jonathan Tan 28 February 2017, 02:53:11 UTC http: attempt updating base URL only if no error http.c supports HTTP redirects of the form http://foo/info/refs?service=git-upload-pack -> http://anything -> http://bar/info/refs?service=git-upload-pack (that is to say, as long as the Git part of the path and the query string is preserved in the final redirect destination, the intermediate steps can have any URL). However, if one of the intermediate steps results in an HTTP exception, a confusing "unable to update url base from redirection" message is printed instead of a Curl error message with the HTTP exception code. This was introduced by 2 commits. Commit c93c92f ("http: update base URLs when we see redirects", 2013-09-28) introduced a best-effort optimization that required checking if only the "base" part of the URL differed between the initial request and the final redirect destination, but it performed the check before any HTTP status checking was done. If something went wrong, the normal code path was still followed, so this did not cause any confusing error messages until commit 6628eb4 ("http: always update the base URL for redirects", 2016-12-06), which taught http to die if the non-"base" part of the URL differed. Therefore, teach http to check the HTTP status before attempting to check if only the "base" part of the URL differed. This commit teaches http_request_reauth to return early without updating options->base_url upon an error; the only invoker of this function that passes a non-NULL "options" is remote-curl.c (through "http_get_strbuf"), which only uses options->base_url for an informational message in the situations that this commit cares about (that is, when the return value is not HTTP_OK). The included test checks that the redirect scheme at the beginning of this commit message works, and that returning a 502 in the middle of the redirect scheme produces the correct result. Note that this is different from the test in commit 6628eb4 ("http: always update the base URL for redirects", 2016-12-06) in that this commit tests that a Git-shaped URL (http://.../info/refs?service=git-upload-pack) works, whereas commit 6628eb4 tests that a non-Git-shaped URL (http://.../info/refs/foo?service=git-upload-pack) does not work (even though Git is processing that URL) and is an error that is fatal, not silently swallowed. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 February 2017, 19:35:53 UTC
b803ae4 Patrick Steinhardt 28 February 2017, 08:59:05 UTC docs/diffcore: unquote "Complete Rewrites" in headers The gitdiffcore documentation quotes the term "Complete Rewrites" in headers for no real gain. This would make sense if the term could be easily confused if not properly grouped together. But actually, the term is quite obvious and thus does not really need any quoting, especially regarding that it is not used anywhere else. But more importanly, this brings up a bug when rendering man pages: when trying to render quotes inside of a section header, we end up with quotes which have been misaligned to the end of line. E.g. diffcore-break: For Splitting Up Complete Rewrites -------------------------------------------------- renders as DIFFCORE-BREAK: FOR SPLITTING UP COMPLETE REWRITES"" , which is obviously wrong. While this is fixable for the man pages by using double-quotes (e.g. ""COMPLETE REWRITES""), this again breaks it for our generated HTML pages. So fix the issue by simply dropping quotes inside of section headers, which is currently only done for the term "Complete Rewrites". Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 February 2017, 19:34:38 UTC
1aa3819 Patrick Steinhardt 28 February 2017, 08:59:04 UTC docs/diffcore: fix grammar in diffcore-rename header Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 February 2017, 19:34:36 UTC
a78d925 Ævar Arnfjörð Bjarmason 27 February 2017, 11:26:28 UTC cvs tests: skip tests that call "cvs commit" when running as root Change the tests that fail to when we run the test suite as root, due to calling "cvs commit". The GNU cvs package has an optional compile-time CVS_BADROOT flag. When compiled with this flag "cvs commit" will refuse to commit anything as root. On my Debian box this isn't compiled in[1] in, but on CentOS it is. I've run all the t/t*cvs*.sh tests, and these are the only two that fail. For some reason e.g. t9402-git-cvsserver-refs.sh still works as root despite doing "cvs commit", I haven't dug into why. This commit is technically being overzealous, we could do better by making a mock cvs commit as root and run the tests if that works, but I don't see any compelling reason to bend over backwards to run these tests in all cases, just skipping them as root seems good enough. 1. Per: strings /usr/bin/cvs|grep 'is not allowed to commit' Using cvs 1.11.23 on CentOS, 1.12.13-MirDebian-18 on Debian. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 February 2017, 19:34:53 UTC
f0252ca Jeff King 27 February 2017, 09:29:31 UTC t6300: avoid creating refs/heads/HEAD In one test, we use "git checkout --orphan HEAD" to create an unborn branch. Confusingly, the resulting branch is named "refs/heads/HEAD". The original probably meant something like: git checkout --orphan orphaned-branch HEAD Let's just use "orphaned-branch" here to make this less confusing. Putting HEAD in the second argument is already implied. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 February 2017, 19:33:44 UTC
b072504 René Scharfe 25 February 2017, 19:27:40 UTC commit: don't check for space twice when looking for header Both standard_header_field() and excluded_header_field() check if there's a space after the buffer that's handed to them. We already check in the caller if that space is present. Don't bother calling the functions if it's missing, as they are guaranteed to return 0 in that case, and remove the now redundant checks from them. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 February 2017, 19:20:18 UTC
50a01cc René Scharfe 25 February 2017, 19:21:52 UTC commit: be more precise when searching for headers Search for a space character only within the current line in read_commit_extra_header_lines() instead of searching in the whole buffer (and possibly beyond, if it's not NUL-terminated) and then discarding any results after the end of the current line. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 February 2017, 19:20:17 UTC
33ad9dd René Scharfe 25 February 2017, 16:00:33 UTC strbuf: add strbuf_add_real_path() Add a function for appending the canonized absolute pathname of a given path to a strbuf. It keeps the existing contents intact, as expected of a function of the strbuf_add() family, while avoiding copying the result if the given strbuf is empty. It's more consistent with the rest of the strbuf API than strbuf_realpath(), which it's wrapping. Also add a semantic patch demonstrating its intended usage and apply it to the current tree. Using strbuf_add_real_path() instead of calling strbuf_addstr() and real_path() avoids an extra copy to a static buffer. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 February 2017, 19:02:06 UTC
3f64699 René Scharfe 25 February 2017, 10:30:03 UTC cocci: use ALLOC_ARRAY Add a semantic patch for using ALLOC_ARRAY to allocate arrays and apply the transformation on the current source tree. The macro checks for multiplication overflow and infers the element size automatically; the result is shorter and safer code. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 February 2017, 19:02:05 UTC
886ddf4 René Scharfe 25 February 2017, 10:02:28 UTC sha1_file: release fallback base's memory in unpack_entry() If a pack entry that's used as a delta base is corrupt, unpack_entry() marks it as unusable and then searches the object again in the hope that it can be found in another pack or in a loose file. The memory for this external base object is never released. Free it after use. Signed-off-by: Rene Scharfe <l.s.r@web.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 February 2017, 19:00:30 UTC
40a18fc Jeff King 25 February 2017, 19:18:31 UTC http: add an "auto" mode for http.emptyauth This variable needs to be specified to make some types of non-basic authentication work, but ideally this would just work out of the box for everyone. However, simply setting it to "1" by default introduces an extra round-trip for cases where it _isn't_ useful. We end up sending a bogus empty credential that the server rejects. Instead, let's introduce an automatic mode, that works like this: 1. We won't try to send the bogus credential on the first request. We'll wait to get an HTTP 401, as usual. 2. After seeing an HTTP 401, the empty-auth hack will kick in only when we know there is an auth method available that might make use of it (i.e., something besides "Basic" or "Digest"). That should make it work out of the box, without incurring any extra round-trips for people hitting Basic-only servers. This _does_ incur an extra round-trip if you really want to use "Basic" but your server advertises other methods (the emptyauth hack will kick in but fail, and then Git will actually ask for a password). The auto mode may incur an extra round-trip over setting http.emptyauth=true, because part of the emptyauth hack is to feed this blank password to curl even before we've made a single request. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 February 2017, 18:35:24 UTC
9d33439 Johan Hovold 20 February 2017, 11:44:06 UTC send-email: only allow one address per body tag Adding comments after a tag in the body is a common practise (e.g. in the Linux kernel) and git-send-email has been supporting this for years by removing any trailing cruft after the address. After some recent changes, any trailing comment is now instead appended to the recipient name (with some random white space inserted) resulting in undesirable noise in the headers, for example: CC: "# 3 . 3 . x : 1b9508f : sched : Rate-limit newidle" <stable@vger.kernel.org> Revert to the earlier behaviour of discarding anything after the (first) address in a tag while parsing the body. Note that multiple addresses after are still allowed after a command line switch (and in a CC header field). Also note that --suppress-cc=self was never honoured when using multiple addresses in a tag. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 February 2017, 18:02:55 UTC
ad8c7cd Jeff King 24 February 2017, 21:08:16 UTC parse_hide_refs_config: tell parse_config_key we don't want a subsection This lets us avoid declaring some otherwise useless variables. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 February 2017, 21:22:12 UTC
48f8d9f Jeff King 24 February 2017, 21:08:02 UTC parse_config_key: allow matching single-level config The parse_config_key() function was introduced to make it easier to match "section.subsection.key" variables. It also handles the simpler "section.key", and the caller is responsible for distinguishing the two from its out-parameters. Most callers who _only_ want "section.key" would just use a strcmp(var, "section.key"), since there is no parsing required. However, they may still use parse_config_key() if their "section" variable isn't a constant (an example of this is in parse_hide_refs_config). Using the parse_config_key is a bit clunky, though: const char *subsection; int subsection_len; const char *key; if (!parse_config_key(var, section, &subsection, &subsection_len, &key) && !subsection) { /* matched! */ } Instead, let's treat a NULL subsection as an indication that the caller does not expect one. That lets us write: const char *key; if (!parse_config_key(var, section, NULL, NULL, &key)) { /* matched! */ } Existing callers should be unaffected, as passing a NULL subsection would currently segfault. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 February 2017, 21:22:11 UTC
e3394fd Jeff King 24 February 2017, 21:07:19 UTC parse_config_key: use skip_prefix instead of starts_with This saves us having to repeatedly add in "section_len" (and also avoids walking over the first part of the string multiple times for a strlen() and strrchr()). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 February 2017, 21:22:09 UTC
49624d1 Stefan Beller 24 February 2017, 20:43:35 UTC refs: parse_hide_refs_config to use parse_config_key parse_config_key was introduced in 1b86bbb0ade (config: add helper function for parsing key names, 2013-01-22), the NEEDSWORK that is removed in this patch was introduced at daebaa7813 (upload/receive-pack: allow hiding ref hierarchies, 2013-01-18), which is only a couple days apart, so presumably the code replaced in this patch was only introduced due to not wanting to wait on the proper helper function being available. Make the condition easier to read by using parse_config_key. Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 February 2017, 20:49:29 UTC
e7e07d5 Junio C Hamano 24 February 2017, 18:49:58 UTC Git 2.12 Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 February 2017, 18:49:58 UTC
cca4f20 Junio C Hamano 24 February 2017, 18:48:10 UTC Merge branch 'ps/doc-gc-aggressive-depth-update' Doc update. * ps/doc-gc-aggressive-depth-update: docs/git-gc: fix default value for `--aggressiveDepth` 24 February 2017, 18:48:10 UTC
dc9ded4 Junio C Hamano 24 February 2017, 18:48:10 UTC Merge branch 'bc/worktree-doc-fix-detached' Doc update. * bc/worktree-doc-fix-detached: Documentation: correctly spell git worktree --detach 24 February 2017, 18:48:10 UTC
c6788b1 Junio C Hamano 24 February 2017, 18:48:09 UTC Merge branch 'dr/doc-check-ref-format-normalize' Doc update. * dr/doc-check-ref-format-normalize: git-check-ref-format: clarify documentation for --normalize 24 February 2017, 18:48:09 UTC
eccf97c Junio C Hamano 24 February 2017, 18:48:09 UTC Merge branch 'gp/document-dotfiles-in-templates-are-not-copied' Doc update. * gp/document-dotfiles-in-templates-are-not-copied: init: document dotfiles exclusion on template copy 24 February 2017, 18:48:09 UTC
c0588fd Junio C Hamano 24 February 2017, 18:48:08 UTC Merge branch 'rt/align-add-i-help-text' Doc update. * rt/align-add-i-help-text: git add -i: replace \t with blanks in the help message 24 February 2017, 18:48:08 UTC
af4027f Junio C Hamano 24 February 2017, 18:48:07 UTC Merge branch 'bc/blame-doc-fix' Doc update. * bc/blame-doc-fix: Documentation: use brackets for optional arguments 24 February 2017, 18:48:08 UTC
7e82388 Patrick Steinhardt 24 February 2017, 08:46:45 UTC docs/git-gc: fix default value for `--aggressiveDepth` In commit 07e7dbf0d (gc: default aggressive depth to 50, 2016-08-11), the default aggressive depth of git-gc has been changed to 50. While git-config(1) has been updated to represent the new default value, git-gc(1) still mentions the old value. This patch fixes it. Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 February 2017, 17:59:12 UTC
cc24d7d Junio C Hamano 24 February 2017, 17:55:41 UTC Merge tag 'l10n-2.12.0-rnd2' of git://github.com/git-l10n/git-po l10n-2.12.0-rnd2 * tag 'l10n-2.12.0-rnd2' of git://github.com/git-l10n/git-po: (22 commits) l10n: zh_CN: for git v2.12.0 l10n round 2 l10n: Update Catalan translation l10n: pt_PT: update Portuguese tranlation l10n: sv.po: Update Swedish translation (3139t0f0u) l10n: de.po: translate 241 messages l10n: ko.po: Update Korean translation l10n: vi.po (3139t): Updated 2 new messages for rc1 l10n: fr.po: v2.12.0 round 2 3139t l10n: git.pot: v2.12.0 round 2 (2 new) l10n: vi.po: Updated Vietnamese translation (3137t) l10n: update Catalan translation l10n: sv.po: Update Swedish translation (3137t0f0u) l10n: fr.po: v2.11-rc0 first round l10n: ko.po: Update Korean translation l10n: fr.po: Fix a typo in the French translation l10n: fr.po: Remove gender specific adjectives l10n: fr.po: Fix typos l10n: git.pot: v2.12.0 round 1 (239 new, 15 removed) l10n: bg: Updated Bulgarian translation (2913t+0f+0u) l10n: fixes to Catalan translation ... 24 February 2017, 17:55:41 UTC
1a79b2f Jiang Xin 27 January 2017, 14:50:57 UTC l10n: zh_CN: for git v2.12.0 l10n round 2 Translate 241 messages (3139t0f0u) for git v2.12.0-rc1. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> 24 February 2017, 16:19:14 UTC
a14eee8 Jordi Mas 21 February 2017, 17:32:29 UTC l10n: Update Catalan translation Signed-off-by: Jordi Mas <jmas@softcatala.org> 24 February 2017, 16:14:55 UTC
1274a15 Junio C Hamano 23 February 2017, 23:04:40 UTC config: use git_config_parse_key() in git_config_parse_parameter() The parsing of one-shot assignments of configuration variables that come from the command line historically was quite loose and allowed anything to pass. It also downcased everything in the variable name, even a three-level <section>.<subsection>.<variable> name in which the <subsection> part must be treated in a case sensitive manner. Existing git_config_parse_key() helper is used to parse the variable name that comes from the command line, i.e. "git config VAR VAL", and handles these details correctly. Replace the strbuf_tolower() call in git_config_parse_parameter() with a call to it to correct both issues. git_config_parse_key() does a bit more things that are not necessary for the purpose of this codepath (e.g. it allocates a separate buffer to return the canonicalized variable name because it takes a "const char *" input), but we are not in a performance-critical codepath here. Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 February 2017, 06:03:03 UTC
ee98df3 Junio C Hamano 23 February 2017, 22:44:07 UTC config: move a few helper functions up git_config_parse_key() implements the validation and downcasing of <section> and <variable> in "<section>[.<subsection>].<variable>" configuration variable name. Move it (and helpers it uses) a bit up so that it can be used by git_config_parse_parameter(), which is used to check configuration settings that are given on the command line (i.e. "git -c VAR=VAL cmd"), in a later patch. Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 February 2017, 22:44:07 UTC
9442555 Jeff King 23 February 2017, 08:17:08 UTC ident: do not ignore empty config name/email When we read user.name and user.email from a config file, they go into strbufs. When a caller asks ident_default_name() for the value, we fallback to auto-detecting if the strbuf is empty. That means that explicitly setting an empty string in the config is identical to not setting it at all. This is potentially confusing, as we usually accept a configured value as the final value. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 February 2017, 20:58:47 UTC
13b9a24 Jeff King 23 February 2017, 08:15:55 UTC ident: reject all-crud ident name An ident name consisting of only "crud" characters (like whitespace or punctuation) is effectively the same as an empty one, because our strbuf_addstr_without_crud() will remove those characters. We reject an empty name when formatting a strict ident, but don't notice an all-crud one because our check happens before the crud-removal step. We could skip past the crud before checking for an empty name, but let's make it a separate code path, for two reasons. One is that we can give a more specific error message. And two is that unlike a blank name, we probably don't want to kick in the fallback-to-username behavior. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 February 2017, 20:47:02 UTC
862e80a Jeff King 23 February 2017, 08:13:53 UTC ident: handle NULL email when complaining of empty name If we see an empty name, we complain about and mention the matching email in the error message (to give it some context). However, the "email" pointer may be NULL here if we were planning to fill it in later from ident_default_email(). This was broken by 59f929596 (fmt_ident: refactor strictness checks, 2016-02-04). Prior to that commit, we would look up the default name and email before doing any other actions. So one solution would be to go back to that. However, we can't just do so blindly. The logic for handling the "!email" condition has grown since then. In particular, looking up the default email can die if getpwuid() fails, but there are other errors that should take precedence. Commit 734c7789a (ident: check for useConfigOnly before auto-detection of name/email, 2016-03-30) reordered the checks so that we prefer the error message for useConfigOnly. Instead, we can observe that while the name-handling depends on "email" being set, the reverse is not true. So we can simply set up the email variable first. This does mean that if both are bogus, we'll complain about the email before the name. But between the two, there is no reason to prefer one over the other. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 February 2017, 20:46:00 UTC
afb6c30 Jeff King 23 February 2017, 08:12:30 UTC ident: mark error messages for translation We already translate the big "please tell me who you are" hint, but missed the individual error messages that go with it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 February 2017, 20:44:20 UTC
bdb31ea Jonathan Tan 23 February 2017, 18:43:03 UTC upload-pack: report "not our ref" to client Make upload-pack report "not our ref" errors to the client as an "ERR" line. (If not, the client would be left waiting for a response when the server is already dead.) Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 February 2017, 20:14:40 UTC
840398f Jeff King 22 February 2017, 23:34:37 UTC http: restrict auth methods to what the server advertises By default, we tell curl to use CURLAUTH_ANY, which does not limit its set of auth methods. However, this results in an extra round-trip to the server when authentication is required. After we've fed the credential to curl, it wants to probe the server to find its list of available methods before sending an Authorization header. We can shortcut this by limiting our http_auth_methods by what the server told us it supports. In some cases (such as when the server only supports Basic), that lets curl skip the extra probe request. The end result should look the same to the user, but you can use GIT_TRACE_CURL to verify the sequence of requests: GIT_TRACE_CURL=1 \ git ls-remote https://example.com/repo.git \ 2>&1 >/dev/null | egrep '(Send|Recv) header: (GET|HTTP|Auth)' Before this patch, hitting a Basic-only server like github.com results in: Send header: GET /repo.git/info/refs?service=git-upload-pack HTTP/1.1 Recv header: HTTP/1.1 401 Authorization Required Send header: GET /repo.git/info/refs?service=git-upload-pack HTTP/1.1 Recv header: HTTP/1.1 401 Authorization Required Send header: GET /repo.git/info/refs?service=git-upload-pack HTTP/1.1 Send header: Authorization: Basic <redacted> Recv header: HTTP/1.1 200 OK And after: Send header: GET /repo.git/info/refs?service=git-upload-pack HTTP/1.1 Recv header: HTTP/1.1 401 Authorization Required Send header: GET /repo.git/info/refs?service=git-upload-pack HTTP/1.1 Send header: Authorization: Basic <redacted> Recv header: HTTP/1.1 200 OK The possible downsides are: - This only helps for a Basic-only server; for a server with multiple auth options, curl may still send a probe request to see which ones are available (IOW, there's no way to say "don't probe, I already know what the server will say"). - The http_auth_methods variable is global, so this will apply to all further requests. That's acceptable for Git's usage of curl, though, which also treats the credentials as global. I.e., in any given program invocation we hit only one conceptual server (we may be redirected at the outset, but in that case that's whose auth_avail field we'd see). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 February 2017, 19:11:56 UTC
e06cdf1 Vasco Almeida 05 February 2017, 18:43:34 UTC l10n: pt_PT: update Portuguese tranlation Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> 23 February 2017, 17:14:55 UTC
e519ecc Ralf Thielow 22 February 2017, 18:46:27 UTC git add -i: replace \t with blanks in the help message Within the help message of 'git add -i', the 'diff' command uses one tab character and blanks to create the space between the name and the description while the others use blanks only. So if the tab size is not at 4 characters, this description will not be in range. Replace the tab character with blanks. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 February 2017, 20:51:00 UTC
2b35a9f brian m. carlson 22 February 2017, 12:25:46 UTC Documentation: use brackets for optional arguments The documentation for git blame used vertical bars for optional arguments to -M and -C, which is unusual and potentially confusing. Since most man pages use brackets for optional items, and that's consistent with how we document the same options for git diff and friends, use brackets here, too. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 February 2017, 18:22:15 UTC
9993a7c brian m. carlson 22 February 2017, 12:34:42 UTC Documentation: correctly spell git worktree --detach The option is “--detach”, but we accidentally spelled it “--detached” at one point in the man page. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Reported-by: Casey Rodarmor <casey@rodarmor.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 February 2017, 18:08:38 UTC
20690b2 Ross Lagerwall 18 February 2017, 00:23:41 UTC remote: ignore failure to remove missing branch.<name>.merge It is not all too unusual for a branch to use "branch.<name>.remote" without "branch.<name>.merge". You may be using the 'push.default' configuration set to 'current', for example, and do $ git checkout -b side colleague/side $ git config branch.side.remote colleague However, "git remote rm" to remove the remote used in such a manner fails with "fatal: could not unset 'branch.<name>.merge'" because it assumes that a branch that has .remote defined must also have .merge defined. Detect the "cannot unset because it is not set to begin with" case and ignore it. Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 February 2017, 21:57:41 UTC
115a40a Damien Regad 19 February 2017, 22:32:32 UTC git-check-ref-format: clarify documentation for --normalize Use of 'iff' may be confusing to people not familiar with this term. Improving the --normalize option's documentation to remove the use of 'iff', and clearly describe what happens when the condition is not met. Signed-off-by: Damien Regad <dregad@mantisbt.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 February 2017, 21:02:42 UTC
28159ae Jiang Xin 21 February 2017, 16:06:44 UTC Merge branch 'master' of git://github.com/nafmo/git-l10n-sv * 'master' of git://github.com/nafmo/git-l10n-sv: l10n: sv.po: Update Swedish translation (3139t0f0u) 21 February 2017, 16:06:44 UTC
back to top