Skip to main content

Browse the archive

https://github.com/git/git
31 May 2024, 23:06:24 UTC
sort by:
Revision Author Date Message Commit Date
7654286 Junio C Hamano 17 March 2016, 17:00:44 UTC Git 2.4.11 Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 March 2016, 18:23:05 UTC
32c6dca Junio C Hamano 17 March 2016, 16:55:54 UTC Merge branch 'jk/path-name-safety-2.4' into maint-2.4 Bugfix patches were backported from the 'master' front to plug heap corruption holes, to catch integer overflow in the computation of pathname lengths, and to get rid of the name_path API. Both of these would have resulted in writing over an under-allocated buffer when formulating pathnames while tree traversal. * jk/path-name-safety-2.4: list-objects: pass full pathname to callbacks list-objects: drop name_path entirely list-objects: convert name_path to a strbuf show_object_with_name: simplify by using path_name() http-push: stop using name_path tree-diff: catch integer overflow in combine_diff_path allocation add helpers for detecting size_t overflow 17 March 2016, 18:22:24 UTC
2824e18 Jeff King 11 February 2016, 22:28:36 UTC list-objects: pass full pathname to callbacks When we find a blob at "a/b/c", we currently pass this to our show_object_fn callbacks as two components: "a/b/" and "c". Callbacks which want the full value then call path_name(), which concatenates the two. But this is an inefficient interface; the path is a strbuf, and we could simply append "c" to it temporarily, then roll back the length, without creating a new copy. So we could improve this by teaching the callsites of path_name() this trick (and there are only 3). But we can also notice that no callback actually cares about the broken-down representation, and simply pass each callback the full path "a/b/c" as a string. The callback code becomes even simpler, then, as we do not have to worry about freeing an allocated buffer, nor rolling back our modification to the strbuf. This is theoretically less efficient, as some callbacks would not bother to format the final path component. But in practice this is not measurable. Since we use the same strbuf over and over, our work to grow it is amortized, and we really only pay to memcpy a few bytes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2016, 17:41:04 UTC
dc06dc8 Jeff King 11 February 2016, 22:26:44 UTC list-objects: drop name_path entirely In the previous commit, we left name_path as a thin wrapper around a strbuf. This patch drops it entirely. As a result, every show_object_fn callback needs to be adjusted. However, none of their code needs to be changed at all, because the only use was to pass it to path_name(), which now handles the bare strbuf. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2016, 17:41:03 UTC
f3badae Jeff King 11 February 2016, 22:26:18 UTC list-objects: convert name_path to a strbuf The "struct name_path" data is examined in only two places: we generate it in process_tree(), and we convert it to a single string in path_name(). Everyone else just passes it through to those functions. We can further note that process_tree() already keeps a single strbuf with the leading tree path, for use with tree_entry_interesting(). Instead of building a separate name_path linked list, let's just use the one we already build in "base". This reduces the amount of code (especially tricky code in path_name() which did not check for integer overflows caused by deep or large pathnames). It is also more efficient in some instances. Any time we were using tree_entry_interesting, we were building up the strbuf anyway, so this is an immediate and obvious win there. In cases where we were not, we trade off storing "pathname/" in a strbuf on the heap for each level of the path, instead of two pointers and an int on the stack (with one pointer into the tree object). On a 64-bit system, the latter is 20 bytes; so if path components are less than that on average, this has lower peak memory usage. In practice it probably doesn't matter either way; we are already holding in memory all of the tree objects leading up to each pathname, and for normal-depth pathnames, we are only talking about hundreds of bytes. This patch leaves "struct name_path" as a thin wrapper around the strbuf, to avoid disrupting callbacks. We should fix them, but leaving it out makes this diff easier to view. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2016, 17:41:03 UTC
8eee9f9 Jeff King 11 February 2016, 22:24:18 UTC show_object_with_name: simplify by using path_name() When "git rev-list" shows an object with its associated path name, it does so by walking the name_path linked list and printing each component (stopping at any embedded NULs or newlines). We'd like to eventually get rid of name_path entirely in favor of a single buffer, and dropping this custom printing code is part of that. As a first step, let's use path_name() to format the list into a single buffer, and print that. This is strictly less efficient than the original, but it's a temporary step in the refactoring; our end game will be to get the fully formatted name in the first place. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2016, 17:41:03 UTC
c6bd2a1 Jeff King 11 February 2016, 22:23:48 UTC http-push: stop using name_path The graph traversal code here passes along a name_path to build up the pathname at which we find each blob. But we never actually do anything with the resulting names, making it a waste of code and memory. This usage came in aa1dbc9 (Update http-push functionality, 2006-03-07), and originally the result was passed to "add_object" (which stored it, but didn't really use it, either). But we stopped using that function in 1f1e895 (Add "named object array" concept, 2006-06-19) in favor of storing just the objects themselves. Moreover, the generation of the name in process_tree() is buggy. It sticks "name" onto the end of the name_path linked list, and then passes it down again as it recurses (instead of "entry.path"). So it's a good thing this was unused, as the resulting path for "a/b/c/d" would end up as "a/a/a/a". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2016, 17:41:02 UTC
d770187 Jeff King 19 February 2016, 11:21:30 UTC tree-diff: catch integer overflow in combine_diff_path allocation A combine_diff_path struct has two "flex" members allocated alongside the struct: a string to hold the pathname, and an array of parent pointers. We use an "int" to compute this, meaning we may easily overflow it if the pathname is extremely long. We can fix this by using size_t, and checking for overflow with the st_add helper. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2016, 17:41:02 UTC
935de81 Jeff King 19 February 2016, 11:21:19 UTC add helpers for detecting size_t overflow Performing computations on size_t variables that we feed to xmalloc and friends can be dangerous, as an integer overflow can cause us to allocate a much smaller chunk than we realized. We already have unsigned_add_overflows(), but let's add unsigned_mult_overflows() to that. Furthermore, rather than have each site manually check and die on overflow, we can provide some helpers that will: - promote the arguments to size_t, so that we know we are doing our computation in the same size of integer that will ultimately be fed to xmalloc - check and die on overflow - return the result so that computations can be done in the parameter list of xmalloc. These functions are a lot uglier to use than normal arithmetic operators (you have to do "st_add(foo, bar)" instead of "foo + bar"). To at least limit the damage, we also provide multi-valued versions. So rather than: st_add(st_add(a, b), st_add(c, d)); you can write: st_add4(a, b, c, d); This isn't nearly as elegant as a varargs function, but it's a lot harder to get it wrong. You don't have to remember to add a sentinel value at the end, and the compiler will complain if you get the number of arguments wrong. This patch adds only the numbered variants required to convert the current code base; we can easily add more later if needed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 March 2016, 17:41:02 UTC
a2558fb Junio C Hamano 28 September 2015, 22:29:54 UTC Git 2.4.10 Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 September 2015, 22:30:30 UTC
6343e2f Junio C Hamano 28 September 2015, 22:28:26 UTC Sync with 2.3.10 28 September 2015, 22:28:31 UTC
18b58f7 Junio C Hamano 28 September 2015, 22:00:37 UTC Git 2.3.10 Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 September 2015, 22:26:52 UTC
92cdfd2 Junio C Hamano 28 September 2015, 21:59:28 UTC Merge branch 'jk/xdiff-memory-limits' into maint-2.3 28 September 2015, 21:59:28 UTC
83c4d38 Jeff King 25 September 2015, 21:58:09 UTC merge-file: enforce MAX_XDIFF_SIZE on incoming files The previous commit enforces MAX_XDIFF_SIZE at the interfaces to xdiff: xdi_diff (which calls xdl_diff) and ll_xdl_merge (which calls xdl_merge). But we have another direct call to xdl_merge in merge-file.c. If it were written today, this probably would just use the ll_merge machinery. But it predates that code, and uses slightly different options to xdl_merge (e.g., ZEALOUS_ALNUM). We could try to abstract out an xdi_merge to match the existing xdi_diff, but even that is difficult. Rather than simply report error, we try to treat large files as binary, and that distinction would happen outside of xdi_merge. The simplest fix is to just replicate the MAX_XDIFF_SIZE check in merge-file.c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 September 2015, 21:58:13 UTC
dcd1742 Jeff King 24 September 2015, 23:12:45 UTC xdiff: reject files larger than ~1GB The xdiff code is not prepared to handle extremely large files. It uses "int" in many places, which can overflow if we have a very large number of lines or even bytes in our input files. This can cause us to produce incorrect diffs, with no indication that the output is wrong. Or worse, we may even underallocate a buffer whose size is the result of an overflowing addition. We're much better off to tell the user that we cannot diff or merge such a large file. This patch covers both cases, but in slightly different ways: 1. For merging, we notice the large file and cleanly fall back to a binary merge (which is effectively "we cannot merge this"). 2. For diffing, we make the binary/text distinction much earlier, and in many different places. For this case, we'll use the xdi_diff as our choke point, and reject any diff there before it hits the xdiff code. This means in most cases we'll die() immediately after. That's not ideal, but in practice we shouldn't generally hit this code path unless the user is trying to do something tricky. We already consider files larger than core.bigfilethreshold to be binary, so this code would only kick in when that is circumvented (either by bumping that value, or by using a .gitattribute to mark a file as diffable). In other words, we can avoid being "nice" here, because there is already nice code that tries to do the right thing. We are adding the suspenders to the nice code's belt, so notice when it has been worked around (both to protect the user from malicious inputs, and because it is better to die() than generate bogus output). The maximum size was chosen after experimenting with feeding large files to the xdiff code. It's just under a gigabyte, which leaves room for two obvious cases: - a diff3 merge conflict result on files of maximum size X could be 3*X plus the size of the markers, which would still be only about 3G, which fits in a 32-bit int. - some of the diff code allocates arrays of one int per record. Even if each file consists only of blank lines, then a file smaller than 1G will have fewer than 1G records, and therefore the int array will fit in 4G. Since the limit is arbitrary anyway, I chose to go under a gigabyte, to leave a safety margin (e.g., we would not want to overflow by allocating "(records + 1) * sizeof(int)" or similar. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 September 2015, 21:57:23 UTC
3efb988 Jeff King 24 September 2015, 23:12:23 UTC react to errors in xdi_diff When we call into xdiff to perform a diff, we generally lose the return code completely. Typically by ignoring the return of our xdi_diff wrapper, but sometimes we even propagate that return value up and then ignore it later. This can lead to us silently producing incorrect diffs (e.g., "git log" might produce no output at all, not even a diff header, for a content-level diff). In practice this does not happen very often, because the typical reason for xdiff to report failure is that it malloc() failed (it uses straight malloc, and not our xmalloc wrapper). But it could also happen when xdiff triggers one our callbacks, which returns an error (e.g., outf() in builtin/rerere.c tries to report a write failure in this way). And the next patch also plans to add more failure modes. Let's notice an error return from xdiff and react appropriately. In most of the diff.c code, we can simply die(), which matches the surrounding code (e.g., that is what we do if we fail to load a file for diffing in the first place). This is not that elegant, but we are probably better off dying to let the user know there was a problem, rather than simply generating bogus output. We could also just die() directly in xdi_diff, but the callers typically have a bit more context, and can provide a better message (and if we do later decide to pass errors up, we're one step closer to doing so). There is one interesting case, which is in diff_grep(). Here if we cannot generate the diff, there is nothing to match, and we silently return "no hits". This is actually what the existing code does already, but we make it a little more explicit. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 September 2015, 21:57:10 UTC
f2df310 Junio C Hamano 28 September 2015, 21:46:05 UTC Merge branch 'jk/transfer-limit-redirection' into maint-2.3 28 September 2015, 21:46:05 UTC
df37727 Junio C Hamano 28 September 2015, 21:33:27 UTC Merge branch 'jk/transfer-limit-protocol' into maint-2.3 28 September 2015, 21:33:27 UTC
b258116 Blake Burkhart 22 September 2015, 22:06:20 UTC http: limit redirection depth By default, libcurl will follow circular http redirects forever. Let's put a cap on this so that somebody who can trigger an automated fetch of an arbitrary repository (e.g., for CI) cannot convince git to loop infinitely. The value chosen is 20, which is the same default that Firefox uses. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 September 2015, 22:32:28 UTC
f4113ca Blake Burkhart 22 September 2015, 22:06:04 UTC http: limit redirection to protocol-whitelist Previously, libcurl would follow redirection to any protocol it was compiled for support with. This is desirable to allow redirection from HTTP to HTTPS. However, it would even successfully allow redirection from HTTP to SFTP, a protocol that git does not otherwise support at all. Furthermore git's new protocol-whitelisting could be bypassed by following a redirect within the remote helper, as it was only enforced at transport selection time. This patch limits redirects within libcurl to HTTP, HTTPS, FTP and FTPS. If there is a protocol-whitelist present, this list is limited to those also allowed by the whitelist. As redirection happens from within libcurl, it is impossible for an HTTP redirect to a protocol implemented within another remote helper. When the curl version git was compiled with is too old to support restrictions on protocol redirection, we warn the user if GIT_ALLOW_PROTOCOL restrictions were requested. This is a little inaccurate, as even without that variable in the environment, we would still restrict SFTP, etc, and we do not warn in that case. But anything else means we would literally warn every time git accesses an http remote. This commit includes a test, but it is not as robust as we would hope. It redirects an http request to ftp, and checks that curl complained about the protocol, which means that we are relying on curl's specific error message to know what happened. Ideally we would redirect to a working ftp server and confirm that we can clone without protocol restrictions, and not with them. But we do not have a portable way of providing an ftp server, nor any other protocol that curl supports (https is the closest, but we would have to deal with certificates). [jk: added test and version warning] Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 September 2015, 22:30:39 UTC
5088d3b Jeff King 22 September 2015, 22:03:49 UTC transport: refactor protocol whitelist code The current callers only want to die when their transport is prohibited. But future callers want to query the mechanism without dying. Let's break out a few query functions, and also save the results in a static list so we don't have to re-parse for each query. Based-on-a-patch-by: Blake Burkhart <bburky@bburky.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 September 2015, 22:28:36 UTC
33cfccb Jeff King 16 September 2015, 17:13:12 UTC submodule: allow only certain protocols for submodule fetches Some protocols (like git-remote-ext) can execute arbitrary code found in the URL. The URLs that submodules use may come from arbitrary sources (e.g., .gitmodules files in a remote repository). Let's restrict submodules to fetching from a known-good subset of protocols. Note that we apply this restriction to all submodule commands, whether the URL comes from .gitmodules or not. This is more restrictive than we need to be; for example, in the tests we run: git submodule add ext::... which should be trusted, as the URL comes directly from the command line provided by the user. But doing it this way is simpler, and makes it much less likely that we would miss a case. And since such protocols should be an exception (especially because nobody who clones from them will be able to update the submodules!), it's not likely to inconvenience anyone in practice. Reported-by: Blake Burkhart <bburky@bburky.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 September 2015, 18:35:48 UTC
a5adace Jeff King 16 September 2015, 17:12:52 UTC transport: add a protocol-whitelist environment variable If we are cloning an untrusted remote repository into a sandbox, we may also want to fetch remote submodules in order to get the complete view as intended by the other side. However, that opens us up to attacks where a malicious user gets us to clone something they would not otherwise have access to (this is not necessarily a problem by itself, but we may then act on the cloned contents in a way that exposes them to the attacker). Ideally such a setup would sandbox git entirely away from high-value items, but this is not always practical or easy to set up (e.g., OS network controls may block multiple protocols, and we would want to enable some but not others). We can help this case by providing a way to restrict particular protocols. We use a whitelist in the environment. This is more annoying to set up than a blacklist, but defaults to safety if the set of protocols git supports grows). If no whitelist is specified, we continue to default to allowing all protocols (this is an "unsafe" default, but since the minority of users will want this sandboxing effect, it is the only sensible one). A note on the tests: ideally these would all be in a single test file, but the git-daemon and httpd test infrastructure is an all-or-nothing proposition rather than a test-by-test prerequisite. By putting them all together, we would be unable to test the file-local code on machines without apache. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 September 2015, 18:35:48 UTC
74b6763 Junio C Hamano 04 September 2015, 17:36:00 UTC Git 2.4.9 Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 September 2015, 17:36:14 UTC
ef0e938 Junio C Hamano 04 September 2015, 17:34:19 UTC Sync with 2.3.9 04 September 2015, 17:34:19 UTC
ecad27c Junio C Hamano 04 September 2015, 17:31:34 UTC Git 2.3.9 Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 September 2015, 17:32:15 UTC
8267cd1 Junio C Hamano 04 September 2015, 17:29:28 UTC Sync with 2.2.3 04 September 2015, 17:29:28 UTC
441c4a4 Junio C Hamano 04 September 2015, 17:25:47 UTC Git 2.2.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 September 2015, 17:26:23 UTC
f54cb05 Junio C Hamano 04 September 2015, 17:25:23 UTC Merge branch 'jk/long-paths' into maint-2.2 04 September 2015, 17:25:23 UTC
78f23bd Jeff King 19 August 2015, 18:12:48 UTC show-branch: use a strbuf for reflog descriptions When we show "branch@{0}", we format into a fixed-size buffer using sprintf. This can overflow if you have long branch names. We can fix it by using a temporary strbuf. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 September 2015, 16:48:26 UTC
5015f01 Jeff King 19 August 2015, 18:12:45 UTC read_info_alternates: handle paths larger than PATH_MAX This function assumes that the relative_base path passed into it is no larger than PATH_MAX, and writes into a fixed-size buffer. However, this path may not have actually come from the filesystem; for example, add_submodule_odb generates a path using a strbuf and passes it in. This is hard to trigger in practice, though, because the long submodule directory would have to exist on disk before we would try to open its info/alternates file. We can easily avoid the bug, though, by simply creating the filename on the heap. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 September 2015, 16:36:51 UTC
c29edfe Jeff King 19 August 2015, 18:12:41 UTC notes: use a strbuf in add_non_note When we are loading a notes tree into our internal hash table, we also collect any files that are clearly non-notes. We format the name of the file into a PATH_MAX buffer, but unlike true notes (which cannot be larger than a fanned-out sha1 hash), these tree entries can be arbitrarily long, overflowing our buffer. We can fix this by switching to a strbuf. It doesn't even cost us an extra allocation, as we can simply hand ownership of the buffer over to the non-note struct. This is of moderate security interest, as you might fetch notes trees from an untrusted remote. However, we do not do so by default, so you would have to manually fetch into the notes namespace. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 September 2015, 16:36:28 UTC
f514ef9 Jeff King 19 August 2015, 18:12:37 UTC verify_absent: allow filenames longer than PATH_MAX When unpack-trees wants to know whether a path will overwrite anything in the working tree, we use lstat() to see if there is anything there. But if we are going to write "foo/bar", we can't just lstat("foo/bar"); we need to look for leading prefixes (e.g., "foo"). So we use the lstat cache to find the length of the leading prefix, and copy the filename up to that length into a temporary buffer (since the original name is const, we cannot just stick a NUL in it). The copy we make goes into a PATH_MAX-sized buffer, which will overflow if the prefix is longer than PATH_MAX. How this happens is a little tricky, since in theory PATH_MAX is the biggest path we will have read from the filesystem. But this can happen if: - the compiled-in PATH_MAX does not accurately reflect what the filesystem is capable of - the leading prefix is not _quite_ what is on disk; it contains the next element from the name we are checking. So if we want to write "aaa/bbb/ccc/ddd" and "aaa/bbb" exists, the prefix of interest is "aaa/bbb/ccc". If "aaa/bbb" approaches PATH_MAX, then "ccc" can overflow it. So this can be triggered, but it's hard to do. In particular, you cannot just "git clone" a bogus repo. The verify_absent checks happen before unpack-trees writes anything to the filesystem, so there are never any leading prefixes during the initial checkout, and the bug doesn't trigger. And by definition, these files are larger than PATH_MAX, so writing them will fail, and clone will complain (though it may write a partial path, which will cause a subsequent "git checkout" to hit the bug). We can fix it by creating the temporary path on the heap. The extra malloc overhead is not important, as we are already making at least one stat() call (and probably more for the prefix discovery). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 September 2015, 15:50:50 UTC
8545932 Junio C Hamano 03 August 2015, 17:40:37 UTC Git 2.4.8 Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 August 2015, 17:43:01 UTC
29dce32 Junio C Hamano 03 August 2015, 17:41:34 UTC Merge branch 'js/rebase-i-clean-up-upon-continue-to-skip' into maint Abandoning an already applied change in "git rebase -i" with "--continue" left CHERRY_PICK_HEAD and confused later steps. * js/rebase-i-clean-up-upon-continue-to-skip: rebase -i: do not leave a CHERRY_PICK_HEAD file behind t3404: demonstrate CHERRY_PICK_HEAD bug 03 August 2015, 17:41:34 UTC
de67af4 Junio C Hamano 03 August 2015, 17:41:33 UTC Merge branch 'ss/clone-guess-dir-name-simplify' into maint Code simplification. * ss/clone-guess-dir-name-simplify: clone: simplify string handling in guess_dir_name() 03 August 2015, 17:41:33 UTC
44737c4 Junio C Hamano 03 August 2015, 17:41:33 UTC Merge branch 'sg/completion-commit-cleanup' into maint * sg/completion-commit-cleanup: completion: teach 'scissors' mode to 'git commit --cleanup=' 03 August 2015, 17:41:33 UTC
c36e465 Junio C Hamano 03 August 2015, 17:41:32 UTC Merge branch 'pt/am-abort-fix' into maint Various fixes around "git am" that applies a patch to a history that is not there yet. * pt/am-abort-fix: am --abort: keep unrelated commits on unborn branch am --abort: support aborting to unborn branch am --abort: revert changes introduced by failed 3way merge am --skip: support skipping while on unborn branch am -3: support 3way merge on unborn branch am --skip: revert changes introduced by failed 3way merge 03 August 2015, 17:41:32 UTC
0533a9b Junio C Hamano 03 August 2015, 17:41:31 UTC Merge branch 'mh/reporting-broken-refs-from-for-each-ref' into maint "git for-each-ref" reported "missing object" for 0{40} when it encounters a broken ref. The lack of object whose name is 0{40} is not the problem; the ref being broken is. * mh/reporting-broken-refs-from-for-each-ref: read_loose_refs(): treat NULL_SHA1 loose references as broken read_loose_refs(): simplify function logic for-each-ref: report broken references correctly t6301: new tests of for-each-ref error handling 03 August 2015, 17:41:31 UTC
a94594d Junio C Hamano 03 August 2015, 17:41:30 UTC Merge branch 'sg/commit-cleanup-scissors' into maint "git commit --cleanup=scissors" was not careful enough to protect against getting fooled by a line that looked like scissors. * sg/commit-cleanup-scissors: commit: cope with scissors lines in commit message 03 August 2015, 17:41:30 UTC
ca00f80 Junio C Hamano 27 July 2015, 19:25:42 UTC Git 2.4.7 Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 July 2015, 19:25:42 UTC
caac7a3 Junio C Hamano 27 July 2015, 19:21:48 UTC Merge branch 'jk/pretty-encoding-doc' into maint Doc update. * jk/pretty-encoding-doc: docs: clarify that --encoding can produce invalid sequences 27 July 2015, 19:21:48 UTC
ff132a1 Junio C Hamano 27 July 2015, 19:21:47 UTC Merge branch 'tb/checkout-doc' into maint Doc update. * tb/checkout-doc: git-checkout.txt: document "git checkout <pathspec>" better 27 July 2015, 19:21:47 UTC
3afcec9 Junio C Hamano 27 July 2015, 19:21:47 UTC Merge branch 'ls/hint-rev-list-count' into maint * ls/hint-rev-list-count: rev-list: add --count to usage guide 27 July 2015, 19:21:47 UTC
315b3ba Junio C Hamano 27 July 2015, 19:21:46 UTC Merge branch 'mm/branch-doc-updates' into maint * mm/branch-doc-updates: Documentation/branch: document -M and -D in terms of --force Documentation/branch: document -d --force and -m --force 27 July 2015, 19:21:46 UTC
bde6a72 Junio C Hamano 27 July 2015, 19:21:45 UTC Merge branch 'jc/fsck-retire-require-eoh' into maint A fix to a minor regression to "git fsck" in v2.2 era that started complaining about a body-less tag object when it lacks a separator empty line after its header to separate it with a non-existent body. * jc/fsck-retire-require-eoh: fsck: it is OK for a tag and a commit to lack the body 27 July 2015, 19:21:46 UTC
c185936 Junio C Hamano 27 July 2015, 19:21:44 UTC Merge branch 'et/http-proxyauth' into maint We used to ask libCURL to use the most secure authentication method available when talking to an HTTP proxy only when we were told to talk to one via configuration variables. We now ask libCURL to always use the most secure authentication method, because the user can tell libCURL to use an HTTP proxy via an environment variable without using configuration variables. * et/http-proxyauth: http: always use any proxy auth method available 27 July 2015, 19:21:44 UTC
342c14d Junio C Hamano 27 July 2015, 19:21:43 UTC Merge branch 'jc/unexport-git-pager-in-use-in-pager' into maint When you say "!<ENTER>" while running say "git log", you'd confuse yourself in the resulting shell, that may look as if you took control back to the original shell you spawned "git log" from but that isn't what is happening. To that new shell, we leaked GIT_PAGER_IN_USE environment variable that was meant as a local communication between the original "Git" and subprocesses that was spawned by it after we launched the pager, which caused many "interesting" things to happen, e.g. "git diff | cat" still paints its output in color by default. Stop leaking that environment variable to the pager's half of the fork; we only need it on "Git" side when we spawn the pager. * jc/unexport-git-pager-in-use-in-pager: pager: do not leak "GIT_PAGER_IN_USE" to the pager 27 July 2015, 19:21:44 UTC
3b175fb Junio C Hamano 27 July 2015, 19:21:43 UTC Merge branch 'mh/strbuf-read-file-returns-ssize-t' into maint Avoid possible ssize_t to int truncation. * mh/strbuf-read-file-returns-ssize-t: strbuf: strbuf_read_file() should return ssize_t 27 July 2015, 19:21:43 UTC
6f402a9 Junio C Hamano 27 July 2015, 19:21:42 UTC Merge branch 'kb/config-unmap-before-renaming' into maint "git config" failed to update the configuration file when the underlying filesystem is incapable of renaming a file that is still open. * kb/config-unmap-before-renaming: config.c: fix writing config files on Windows network shares 27 July 2015, 19:21:42 UTC
726359b Junio C Hamano 27 July 2015, 19:21:42 UTC Merge branch 'jk/rev-list-no-bitmap-while-pruning' into maint A minor bugfix when pack bitmap is used with "rev-list --count". * jk/rev-list-no-bitmap-while-pruning: rev-list: disable --use-bitmap-index when pruning commits 27 July 2015, 19:21:42 UTC
aa0b816 Junio C Hamano 27 July 2015, 19:21:41 UTC Merge branch 'rh/test-color-avoid-terminfo-in-original-home' into maint An ancient test framework enhancement to allow color was not entirely correct; this makes it work even when tput needs to read from the ~/.terminfo under the user's real HOME directory. * rh/test-color-avoid-terminfo-in-original-home: test-lib.sh: fix color support when tput needs ~/.terminfo Revert "test-lib.sh: do tests for color support after changing HOME" 27 July 2015, 19:21:41 UTC
7c69600 Junio C Hamano 27 July 2015, 19:21:40 UTC Merge branch 'jk/fix-refresh-utime' into maint Fix a small bug in our use of umask() return value. * jk/fix-refresh-utime: check_and_freshen_file: fix reversed success-check 27 July 2015, 19:21:40 UTC
3f8b439 Junio C Hamano 27 July 2015, 19:21:39 UTC Merge branch 'cb/rebase-am-exit-code' into maint "git rebase" did not exit with failure when format-patch it invoked failed for whatever reason. * cb/rebase-am-exit-code: rebase: return non-zero error code if format-patch fails 27 July 2015, 19:21:39 UTC
de62fe8 Junio C Hamano 27 July 2015, 19:21:38 UTC Merge branch 'jk/index-pack-reduce-recheck' into maint Disable "have we lost a race with competing repack?" check while receiving a huge object transfer that runs index-pack. * jk/index-pack-reduce-recheck: index-pack: avoid excessive re-reading of pack directory 27 July 2015, 19:21:38 UTC
bb3e7b1 Junio C Hamano 15 July 2015, 18:45:42 UTC Git 2.4.6 Signed-off-by: Junio C Hamano <gitster@pobox.com> 15 July 2015, 19:31:07 UTC
b7abfac Junio C Hamano 15 July 2015, 18:41:26 UTC Merge branch 'mm/describe-doc' into maint Docfix. * mm/describe-doc: Documentation/describe: improve one-line summary 15 July 2015, 18:41:26 UTC
51d5980 Junio C Hamano 15 July 2015, 18:41:26 UTC Merge branch 'jc/prompt-document-ps1-state-separator' into maint Docfix. * jc/prompt-document-ps1-state-separator: git-prompt.sh: document GIT_PS1_STATESEPARATOR 15 July 2015, 18:41:26 UTC
3f20927 Junio C Hamano 15 July 2015, 18:41:24 UTC Merge branch 'es/osx-header-pollutes-mask-macro' into maint * es/osx-header-pollutes-mask-macro: ewah: use less generic macro name ewah/bitmap: silence warning about MASK macro redefinition 15 July 2015, 18:41:24 UTC
71a8af6 Junio C Hamano 15 July 2015, 18:41:23 UTC Merge branch 'es/utf8-stupid-compiler-workaround' into maint A compilation workaround. * es/utf8-stupid-compiler-workaround: utf8: NO_ICONV: silence uninitialized variable warning 15 July 2015, 18:41:23 UTC
a15ebbc Junio C Hamano 15 July 2015, 18:41:22 UTC Merge branch 'fk/doc-format-patch-vn' into maint Docfix. * fk/doc-format-patch-vn: doc: format-patch: fix typo 15 July 2015, 18:41:22 UTC
e9da4e6 Junio C Hamano 15 July 2015, 18:41:21 UTC Merge branch 'pt/t0302-needs-sanity' into maint * pt/t0302-needs-sanity: t0302: "unreadable" test needs SANITY prereq 15 July 2015, 18:41:21 UTC
eca143b Junio C Hamano 15 July 2015, 18:41:20 UTC Merge branch 'me/fetch-into-shallow-safety' into maint "git fetch --depth=<depth>" and "git clone --depth=<depth>" issued a shallow transfer request even to an upload-pack that does not support the capability. * me/fetch-into-shallow-safety: fetch-pack: check for shallow if depth given 15 July 2015, 18:41:20 UTC
697f67a Junio C Hamano 15 July 2015, 18:41:19 UTC Merge branch 'mh/fsck-reflog-entries' into maint "git fsck" used to ignore missing or invalid objects recorded in reflog. * mh/fsck-reflog-entries: fsck: report errors if reflog entries point at invalid objects fsck_handle_reflog_sha1(): new function 15 July 2015, 18:41:19 UTC
ada9ecd Junio C Hamano 15 July 2015, 18:41:18 UTC Merge branch 'af/tcsh-completion-noclobber' into maint The tcsh completion writes a bash scriptlet but that would have failed for users with noclobber set. * af/tcsh-completion-noclobber: git-completion.tcsh: fix redirect with noclobber 15 July 2015, 18:41:18 UTC
7c62118 Junio C Hamano 15 July 2015, 18:41:17 UTC Merge branch 'pa/auto-gc-mac-osx' into maint Recent Mac OS X updates breaks the logic to detect that the machine is on the AC power in the sample pre-auto-gc script. * pa/auto-gc-mac-osx: hooks/pre-auto-gc: adjust power checking for newer OS X 15 July 2015, 18:41:17 UTC
93eba05 Junio C Hamano 15 July 2015, 18:41:16 UTC Merge branch 'jc/do-not-feed-tags-to-clear-commit-marks' into maint "git format-patch --ignore-if-upstream A..B" did not like to be fed tags as boundary commits. * jc/do-not-feed-tags-to-clear-commit-marks: format-patch: do not feed tags to clear_commit_marks() 15 July 2015, 18:41:16 UTC
7e837c6 Sebastian Schuberth 09 July 2015, 18:24:08 UTC clone: simplify string handling in guess_dir_name() Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 July 2015, 21:21:29 UTC
3096b2e Jeff King 08 July 2015, 20:33:52 UTC check_and_freshen_file: fix reversed success-check When we want to write out a loose object file, we have always first made sure we don't already have the object somewhere. Since 33d4221 (write_sha1_file: freshen existing objects, 2014-10-15), we also update the timestamp on the file, so that a simultaneous prune knows somebody is likely to reference it soon. If our utime() call fails, we treat this the same as not having the object in the first place; the safe thing to do is write out another copy. However, the loose-object check accidentally inverts the utime() check; it returns failure _only_ when the utime() call actually succeeded. Thus it was failing to protect us there, and in the normal case where utime() succeeds, it caused us to pointlessly write out and link the object. This passed our freshening tests, because writing out the new object is certainly _one_ way of updating its utime. So the normal case was inefficient, but not wrong. While we're here, let's also drop a comment in front of the check_and_freshen functions, making a note of their return type (since it is not our usual "0 for success, -1 for error"). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 July 2015, 22:58:28 UTC
60d708b Clemens Buchacher 02 July 2015, 09:11:33 UTC rebase: return non-zero error code if format-patch fails Since e481af06 (rebase: Handle cases where format-patch fails) we notice if format-patch fails and return immediately from git-rebase--am. We save the return value with ret=$?, but then we return $?, which is usually zero in this case. Fix this by returning $ret instead. Cc: Andrew Wong <andrew.kw.w@gmail.com> Signed-off-by: Clemens Buchacher <clemens.buchacher@intel.com> Helped-by: Jorge Nunes <jorge.nunes@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 08 July 2015, 22:36:42 UTC
83fe167 Matthieu Moy 02 July 2015, 14:07:21 UTC Documentation/branch: document -M and -D in terms of --force Now that we have proper documentation for --force's interaction with -d and -m, we can avoid duplication and consider -M and -D as convenience aliases for -m --force and -d --force. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 July 2015, 17:36:54 UTC
8482d04 Matthieu Moy 02 July 2015, 14:07:20 UTC Documentation/branch: document -d --force and -m --force The --force option was modified in 356e91f (branch: allow -f with -m and -d, 2014-12-08), but the documentation was not updated. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 06 July 2015, 17:36:51 UTC
6c8afe4 Michael Haggerty 03 July 2015, 13:59:32 UTC strbuf: strbuf_read_file() should return ssize_t It is currently declared to return int, which could overflow for large files. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 July 2015, 01:25:02 UTC
124b519 Junio C Hamano 03 July 2015, 17:18:45 UTC pager: do not leak "GIT_PAGER_IN_USE" to the pager Since 2e6c012e (setup_pager: set GIT_PAGER_IN_USE, 2011-08-17), we export GIT_PAGER_IN_USE so that a process that becomes the upstream of the spawned pager can still tell that we have spawned the pager and decide to do colored output even when its output no longer goes to a terminal (i.e. isatty(1)). But we forgot to clear it from the enviornment of the spawned pager. This is not a problem in a sane world, but if you have a handful of thousands Git users in your organization, somebody is bound to do strange things, e.g. typing "!<ENTER>" instead of 'q' to get control back from $LESS. GIT_PAGER_IN_USE is still set in that subshell spawned by "less", and all sorts of interesting things starts happening, e.g. "git diff | cat" starts coloring its output. We can clear the environment variable in the half of the fork that runs the pager to avoid the confusion. Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 July 2015, 01:07:21 UTC
c8a70d3 Jeff King 01 July 2015, 18:42:17 UTC rev-list: disable --use-bitmap-index when pruning commits The reachability bitmaps do not have enough information to tell us which commits might have changed path "foo", so the current code produces wrong answers for: git rev-list --use-bitmap-index --count HEAD -- foo (it silently ignores the "foo" limiter). Instead, we should fall back to doing a normal traversal (it is OK to fall back rather than complain, because --use-bitmap-index is a pure optimization, and might not kick in for other reasons, such as there being no bitmaps in the repository). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 July 2015, 19:00:50 UTC
75d2e5a Lawrence Siebert 01 July 2015, 09:24:11 UTC rev-list: add --count to usage guide --count should be mentioned in the usage guide, this updates code and documentation. Signed-off-by: Lawrence Siebert <lawrencesiebert@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 July 2015, 16:29:11 UTC
7a64592 Karsten Blees 30 June 2015, 14:34:13 UTC config.c: fix writing config files on Windows network shares Renaming to an existing file doesn't work on Windows network shares if the target file is open. munmap() the old config file before commit_lock_file. Signed-off-by: Karsten Blees <blees@dcon.de> Acked-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 30 June 2015, 18:01:59 UTC
0e0aff4 Johannes Schindelin 18 June 2015, 16:38:53 UTC rebase -i: do not leave a CHERRY_PICK_HEAD file behind When skipping commits whose changes were already applied via `git rebase --continue`, we need to clean up said file explicitly. The same is not true for `git rebase --skip` because that will execute `git reset --hard` as part of the "skip" handling in git-rebase.sh, even before git-rebase--interactive.sh is called. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 June 2015, 20:12:43 UTC
d17ec3a Johannes Schindelin 18 June 2015, 16:38:44 UTC t3404: demonstrate CHERRY_PICK_HEAD bug When rev-list's --cherry option does not detect that a patch has already been applied upstream, an interactive rebase would offer to reapply it and consequently stop at that patch with a failure, mentioning that the diff is empty. Traditionally, a `git rebase --continue` simply skips the commit in such a situation. However, as pointed out by Gábor Szeder, this leaves a CHERRY_PICK_HEAD behind, making the Git prompt believe that a cherry pick is still going on. This commit adds a test case demonstrating this bug. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 June 2015, 20:11:37 UTC
5841520 Enrique Tobis 26 June 2015, 18:19:04 UTC http: always use any proxy auth method available We set CURLOPT_PROXYAUTH to use the most secure authentication method available only when the user has set configuration variables to specify a proxy. However, libcurl also supports specifying a proxy through environment variables. In that case libcurl defaults to only using the Basic proxy authentication method, because we do not use CURLOPT_PROXYAUTH. Set CURLOPT_PROXYAUTH to always use the most secure authentication method available, even when there is no git configuration telling us to use a proxy. This allows the user to use environment variables to configure a proxy that requires an authentication method different from Basic. Signed-off-by: Enrique A. Tobis <etobis@twosigma.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 29 June 2015, 16:57:43 UTC
84d18c0 Junio C Hamano 28 June 2015, 18:18:31 UTC fsck: it is OK for a tag and a commit to lack the body When fsck validates a commit or a tag, it scans each line in the header of the object using helper functions such as "start_with()", etc. that work on a NUL terminated buffer, but before a1e920a0 (index-pack: terminate object buffers with NUL, 2014-12-08), the validation functions were fed the object data in a piece of memory that is not necessarily terminated with a NUL. We added a helper function require_end_of_header() to be called at the beginning of these validation functions to insist that the object data contains an empty line before its end. The theory is that the validating functions will notice and stop when it hits an empty line as a normal end of header (or a required header line that is missing) without scanning past the end of potentially not NUL-terminated buffer. But the theory forgot that in the older days, Git itself happily created objects with only the header lines without a body. This caused Git 2.2 and later to issue an unnecessary warning in some existing repositories. With a1e920a0, we do not need to require an empty line (or the body) in these objects to safely parse and validate them. Drop the offending "must have an empty line" check from this helper function, while keeping the other check to make sure that there is no NUL in the header part of the object, and adjust the name of the helper to what it does accordingly. Noticed-by: Wolfgang Denk <wd@denx.de> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 June 2015, 21:47:28 UTC
351d06d Junio C Hamano 26 June 2015, 06:03:26 UTC Merge branch 'jk/stash-require-clean-index' into maint A hotfix for the topic already in 'master'. * jk/stash-require-clean-index: Revert "stash: require a clean index to apply" 26 June 2015, 06:03:27 UTC
b1f0802 Junio C Hamano 26 June 2015, 06:03:25 UTC Merge branch 'cb/array-size' into maint * cb/array-size: Fix definition of ARRAY_SIZE for non-gcc builds 26 June 2015, 06:03:25 UTC
0df0541 Junio C Hamano 25 June 2015, 18:03:05 UTC Git 2.4.5 Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 June 2015, 18:03:05 UTC
ebf4fc9 Junio C Hamano 25 June 2015, 18:02:16 UTC Merge branch 'sg/merge-summary-config' into maint Doc updates. * sg/merge-summary-config: Documentation: include 'merge.branchdesc' for merge and config as well 25 June 2015, 18:02:17 UTC
5fd7227 Junio C Hamano 25 June 2015, 18:02:15 UTC Merge branch 'jk/make-fix-dependencies' into maint Build clean-up. * jk/make-fix-dependencies: Makefile: silence perl/PM.stamp recipe Makefile: avoid timestamp updates to GIT-BUILD-OPTIONS Makefile: drop dependency between git-instaweb and gitweb 25 June 2015, 18:02:16 UTC
68538cf Junio C Hamano 25 June 2015, 18:02:14 UTC Merge branch 'sb/pack-protocol-mention-smart-http' into maint Doc updates. * sb/pack-protocol-mention-smart-http: Documentation/technical/pack-protocol: mention http as possible protocol 25 June 2015, 18:02:14 UTC
f2bd231 Junio C Hamano 25 June 2015, 18:02:13 UTC Merge branch 'jk/die-on-bogus-worktree-late' into maint The setup code used to die when core.bare and core.worktree are set inconsistently, even for commands that do not need working tree. * jk/die-on-bogus-worktree-late: setup_git_directory: delay core.bare/core.worktree errors 25 June 2015, 18:02:13 UTC
6356003 Junio C Hamano 25 June 2015, 18:02:12 UTC Merge branch 'pt/pull-tags-error-diag' into maint There was a dead code that used to handle "git pull --tags" and show special-cased error message, which was made irrelevant when the semantics of the option changed back in Git 1.9 days. * pt/pull-tags-error-diag: pull: remove --tags error in no merge candidates case 25 June 2015, 18:02:12 UTC
6998d89 Junio C Hamano 25 June 2015, 18:02:11 UTC Merge branch 'jk/color-diff-plain-is-context' into maint "color.diff.plain" was a misnomer; give it 'color.diff.context' as a more logical synonym. * jk/color-diff-plain-is-context: diff.h: rename DIFF_PLAIN color slot to DIFF_CONTEXT diff: accept color.diff.context as a synonym for "plain" 25 June 2015, 18:02:11 UTC
c5baf18 Junio C Hamano 25 June 2015, 18:02:10 UTC Merge branch 'jk/diagnose-config-mmap-failure' into maint The configuration reader/writer uses mmap(2) interface to access the files; when we find a directory, it barfed with "Out of memory?". * jk/diagnose-config-mmap-failure: xmmap(): drop "Out of memory?" config.c: rewrite ENODEV into EISDIR when mmap fails config.c: avoid xmmap error messages config.c: fix mmap leak when writing config read-cache.c: drop PROT_WRITE from mmap of index 25 June 2015, 18:02:11 UTC
c533125 Junio C Hamano 25 June 2015, 18:02:09 UTC Merge branch 'jk/squelch-missing-link-warning-for-unreachable' into maint Recent "git prune" traverses young unreachable objects to safekeep old objects in the reachability chain from them, which sometimes caused error messages that are unnecessarily alarming. * jk/squelch-missing-link-warning-for-unreachable: suppress errors on missing UNINTERESTING links silence broken link warnings with revs->ignore_missing_links add quieter versions of parse_{tree,commit} 25 June 2015, 18:02:10 UTC
f249409 Junio C Hamano 25 June 2015, 18:02:09 UTC Merge branch 'mm/rebase-i-post-rewrite-exec' into maint "git rebase -i" fired post-rewrite hook when it shouldn't (namely, when it was told to stop sequencing with 'exec' insn). * mm/rebase-i-post-rewrite-exec: t5407: use <<- to align the expected output rebase -i: fix post-rewrite hook with failed exec command rebase -i: demonstrate incorrect behavior of post-rewrite 25 June 2015, 18:02:09 UTC
e2c6f7c Charles Bailey 24 June 2015, 22:12:07 UTC Fix definition of ARRAY_SIZE for non-gcc builds The improved ARRAY_SIZE macro uses BARF_UNLESS_AN_ARRAY which expands to a valid check for recent gcc versions and to 0 for older gcc versions but is not defined on non-gcc builds. Non-gcc builds need this macro to expand to 0 as well. The current outer test (defined(__GNUC__) && (__GNUC__ >= 3)) is a strictly weaker condition than the inner test (GIT_GNUC_PREREQ(3, 1)) so we can omit the outer test and cause the BARF_UNLESS_AN_ARRAY macro to be defined correctly on non-gcc builds as well as gcc builds with older versions. Signed-off-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 June 2015, 00:14:00 UTC
d5c1b7c Richard Hansen 17 June 2015, 21:11:21 UTC test-lib.sh: fix color support when tput needs ~/.terminfo If tput needs ~/.terminfo for the current $TERM, then tput will succeed before HOME is changed to $TRASH_DIRECTORY (causing color to be set to 't') but fail afterward. One possible way to fix this is to treat HOME like TERM: back up the original value and temporarily restore it before say_color() runs tput. Instead, pre-compute and save the color control sequences before changing either TERM or HOME. Use the saved control sequences in say_color() rather than call tput each time. This avoids the need to back up and restore the TERM and HOME variables, and it avoids the overhead of a subshell and two invocations of tput per call to say_color(). Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2015, 22:16:52 UTC
e479c5f Jeff King 17 June 2015, 18:46:08 UTC docs: clarify that --encoding can produce invalid sequences In the common case that the commit encoding matches the output encoding, we do not touch the buffer at all, which makes things much more efficient. But it might be unclear to a consumer that we will pass through bogus sequences. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2015, 20:46:36 UTC
c4ac525 Torsten Bögershausen 17 June 2015, 07:54:51 UTC git-checkout.txt: document "git checkout <pathspec>" better git checkout <pathspec> can be used to reset changes in the working tree. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2015, 20:33:06 UTC
ca92a66 Richard Hansen 17 June 2015, 19:06:25 UTC Revert "test-lib.sh: do tests for color support after changing HOME" This reverts commit 102fc80d32094ad6598b17ab9d607516ee8edc4a. There are two issues with that commit: * It is buggy. In pseudocode, it is doing: color is set || TERM != dumb && color works && color=t when it should be doing: color is set || { TERM != dumb && color works && color=t } * It unnecessarily disables color when tput needs to read ~/.terminfo to get the control sequences. Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2015, 20:05:00 UTC
eb86a50 Mike Edgar 17 June 2015, 11:48:14 UTC fetch-pack: check for shallow if depth given When a repository is first fetched as a shallow clone, either by git-clone or by fetching into an empty repo, the server's capabilities are not currently consulted. The client will send shallow requests even if the server does not understand them, and the resulting error may be unhelpful to the user. This change pre-emptively checks so we can exit with a helpful error if necessary. Signed-off-by: Mike Edgar <adgar@google.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 June 2015, 19:03:58 UTC
f09bd21 Junio C Hamano 16 June 2015, 21:38:01 UTC Git 2.4.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 16 June 2015, 21:38:01 UTC
back to top