Skip to main content

Browse the archive

swh:1:snp:87728f882295b5ba27035837248a04c5be121c53
sort by:
Revision Author Date Message Commit Date
e568e56 Junio C Hamano 17 March 2016, 17:28:50 UTC Git 2.5.5 Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 March 2016, 18:24:59 UTC
c638f3e Junio C Hamano 17 March 2016, 18:24:14 UTC Merge branch 'maint-2.4' into maint-2.5 * maint-2.4: Git 2.4.11 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:24:14 UTC
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
2435856 Junio C Hamano 28 September 2015, 22:26:49 UTC Git 2.5.4 Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 September 2015, 22:34:28 UTC
11a458b Junio C Hamano 28 September 2015, 22:33:56 UTC Sync with 2.4.10 28 September 2015, 22:33:56 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
ee6ad5f Junio C Hamano 17 September 2015, 19:16:10 UTC Git 2.5.3 Signed-off-by: Junio C Hamano <gitster@pobox.com> 17 September 2015, 19:16:17 UTC
8833ccd Junio C Hamano 17 September 2015, 19:12:29 UTC Merge branch 'dt/untracked-subdir' into maint The experimental untracked-cache feature were buggy when paths with a few levels of subdirectories are involved. * dt/untracked-subdir: untracked cache: fix entry invalidation untracked-cache: fix subdirectory handling t7063: use --force-untracked-cache to speed up a bit untracked-cache: support sparse checkout 17 September 2015, 19:12:29 UTC
d6579d9 Junio C Hamano 17 September 2015, 19:11:46 UTC Merge branch 'br/svn-doc-include-paths-config' into maint * br/svn-doc-include-paths-config: git-svn doc: mention "svn-remote.<name>.include-paths" 17 September 2015, 19:11:46 UTC
cfc3e0e Junio C Hamano 17 September 2015, 19:11:06 UTC Merge branch 'ah/submodule-typofix-in-error' into maint Error string fix. * ah/submodule-typofix-in-error: git-submodule: remove extraneous space from error message 17 September 2015, 19:11:08 UTC
02dad26 Junio C Hamano 17 September 2015, 19:03:02 UTC Merge branch 'js/maint-am-skip-performance-regression' into maint * js/maint-am-skip-performance-regression: am --skip/--abort: merge HEAD/ORIG_HEAD tree into index 17 September 2015, 19:03:02 UTC
b9d6689 Johannes Schindelin 09 September 2015, 09:10:07 UTC am --skip/--abort: merge HEAD/ORIG_HEAD tree into index f8da6801 (am --skip: support skipping while on unborn branch, 2015-06-06) introduced a performance regression to "git am --skip", where it used "read-tree" to reconstruct the index from scratch without reusing the cached stat information. This is a backport of the corresponding patch to the builtin am in 2.6: 3ecc704 (am --skip/--abort: merge HEAD/ORIG_HEAD tree into index, 2015-08-19). Reportedly, it can make a huge difference on Windows, in one case a `git rebase --skip` took 1m40s without, and 5s with, this patch. cf. https://github.com/git-for-windows/git/issues/365 Reported-and-suggested-by: Kim Gybels <kgybels@infogroep.be> Acked-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 09 September 2015, 21:22:56 UTC
27ea6f8 Junio C Hamano 04 September 2015, 17:46:00 UTC Git 2.5.2 Signed-off-by: Junio C Hamano <gitster@pobox.com> 04 September 2015, 17:46:07 UTC
3d3caf0 Junio C Hamano 04 September 2015, 17:43:23 UTC Sync with 2.4.9 04 September 2015, 17:43:23 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
fb8880d Junio C Hamano 04 September 2015, 02:18:05 UTC Merge branch 'ee/clean-test-fixes' into maint * ee/clean-test-fixes: t7300: fix broken && chains 04 September 2015, 02:18:05 UTC
5af77d1 Junio C Hamano 04 September 2015, 02:18:03 UTC Merge branch 'jk/log-missing-default-HEAD' into maint "git init empty && git -C empty log" said "bad default revision 'HEAD'", which was found to be a bit confusing to new users. * jk/log-missing-default-HEAD: log: diagnose empty HEAD more clearly 04 September 2015, 02:18:04 UTC
9d93988 Junio C Hamano 04 September 2015, 02:18:03 UTC Merge branch 'cc/trailers-corner-case-fix' into maint The "interpret-trailers" helper mistook a multi-paragraph title of a commit log message with a colon in it as the end of the trailer block. * cc/trailers-corner-case-fix: trailer: support multiline title trailer: retitle a test and correct an in-comment message trailer: ignore first line of message 04 September 2015, 02:18:03 UTC
311e5ce Junio C Hamano 04 September 2015, 02:18:02 UTC Merge branch 'dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update' into maint When re-priming the cache-tree opportunistically while committing the in-core index as-is, we mistakenly invalidated the in-core index too aggressively, causing the experimental split-index code to unnecessarily rewrite the on-disk index file(s). * dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update: commit: don't rewrite shared index unnecessarily 04 September 2015, 02:18:02 UTC
1c82039 Junio C Hamano 04 September 2015, 02:18:01 UTC Merge branch 'rs/archive-zip-many' into maint "git archive" did not use zip64 extension when creating an archive with more than 64k entries, which nobody should need, right ;-)? * rs/archive-zip-many: archive-zip: support more than 65535 entries archive-zip: use a local variable to store the creator version t5004: test ZIP archives with many entries 04 September 2015, 02:18:01 UTC
ae6ac84 Junio C Hamano 04 September 2015, 02:18:00 UTC Merge branch 'jc/calloc-pathspec' into maint Minor code cleanup. * jc/calloc-pathspec: ps_matched: xcalloc() takes nmemb and then element size 04 September 2015, 02:18:00 UTC
8136099 Junio C Hamano 04 September 2015, 02:17:59 UTC Merge branch 'ss/fix-config-fd-leak' into maint * ss/fix-config-fd-leak: config: close config file handle in case of error 04 September 2015, 02:17:59 UTC
dc4e7b0 Junio C Hamano 04 September 2015, 02:17:57 UTC Merge branch 'sg/wt-status-header-inclusion' into maint * sg/wt-status-header-inclusion: wt-status: move #include "pathspec.h" to the header 04 September 2015, 02:17:57 UTC
659227b Junio C Hamano 04 September 2015, 02:17:56 UTC Merge branch 'po/po-readme' into maint Doc updates for i18n. * po/po-readme: po/README: Update directions for l10n contributors 04 September 2015, 02:17:56 UTC
57a2bb1 Junio C Hamano 04 September 2015, 02:17:54 UTC Merge branch 'sg/t3020-typofix' into maint * sg/t3020-typofix: t3020: fix typo in test description 04 September 2015, 02:17:55 UTC
c1fa16b Junio C Hamano 04 September 2015, 02:17:53 UTC Merge branch 'as/docfix-reflog-expire-unreachable' into maint Docfix. * as/docfix-reflog-expire-unreachable: Documentation/config: fix inconsistent label on gc.*.reflogExpireUnreachable 04 September 2015, 02:17:53 UTC
d6c196a Junio C Hamano 04 September 2015, 02:17:53 UTC Merge branch 'nd/fixup-linked-gitdir' into maint The code in "multiple-worktree" support that attempted to recover from an inconsistent state updated an incorrect file. * nd/fixup-linked-gitdir: setup: update the right file in multiple checkouts 04 September 2015, 02:17:53 UTC
e654e3b Junio C Hamano 04 September 2015, 02:17:52 UTC Merge branch 'jk/rev-list-has-no-notes' into maint "git rev-list" does not take "--notes" option, but did not complain when one is given. * jk/rev-list-has-no-notes: rev-list: make it obvious that we do not support notes 04 September 2015, 02:17:53 UTC
fa6d374 Junio C Hamano 04 September 2015, 02:17:52 UTC Merge branch 'jk/fix-alias-pager-config-key-warnings' into maint Because the configuration system does not allow "alias.0foo" and "pager.0foo" as the configuration key, the user cannot use '0foo' as a custom command name anyway, but "git 0foo" tried to look these keys up and emitted useless warnings before saying '0foo is not a git command'. These warning messages have been squelched. * jk/fix-alias-pager-config-key-warnings: config: silence warnings for command names with invalid keys 04 September 2015, 02:17:52 UTC
0b2cef2 Junio C Hamano 04 September 2015, 02:17:51 UTC Merge branch 'nd/dwim-wildcards-as-pathspecs' into maint Test updates for Windows. * nd/dwim-wildcards-as-pathspecs: t2019: skip test requiring '*' in a file name non Windows 04 September 2015, 02:17:51 UTC
969560b Junio C Hamano 04 September 2015, 02:17:51 UTC Merge branch 'sg/help-group' into maint We rewrote one of the build scripts in Perl but this reimplements in Bourne shell. * sg/help-group: generate-cmdlist: re-implement as shell script 04 September 2015, 02:17:51 UTC
d11448f Junio C Hamano 04 September 2015, 02:17:50 UTC Merge branch 'ps/t1509-chroot-test-fixup' into maint t1509 test that requires a dedicated VM environment had some bitrot, which has been corrected. * ps/t1509-chroot-test-fixup: tests: fix cleanup after tests in t1509-root-worktree tests: fix broken && chains in t1509-root-worktree 04 September 2015, 02:17:50 UTC
8b27071 Junio C Hamano 04 September 2015, 02:17:50 UTC Merge branch 'jh/strbuf-read-use-read-in-full' into maint strbuf_read() used to have one extra iteration (and an unnecessary strbuf_grow() of 8kB), which was eliminated. * jh/strbuf-read-use-read-in-full: strbuf_read(): skip unnecessary strbuf_grow() at eof 04 September 2015, 02:17:50 UTC
6c0850f Junio C Hamano 04 September 2015, 02:17:49 UTC Merge branch 'jk/long-error-messages' into maint The codepath to produce error messages had a hard-coded limit to the size of the message, primarily to avoid memory allocation while calling die(). * jk/long-error-messages: vreportf: avoid intermediate buffer vreportf: report to arbitrary filehandles 04 September 2015, 02:17:49 UTC
cbcd3dc Junio C Hamano 04 September 2015, 02:17:49 UTC Merge branch 'cb/open-noatime-clear-errno' into maint When trying to see that an object does not exist, a state errno leaked from our "first try to open a packfile with O_NOATIME and then if it fails retry without it" logic on a system that refuses O_NOATIME. This confused us and caused us to die, saying that the packfile is unreadable, when we should have just reported that the object does not exist in that packfile to the caller. * cb/open-noatime-clear-errno: git_open_noatime: return with errno=0 on success 04 September 2015, 02:17:49 UTC
03ea027 Junio C Hamano 04 September 2015, 02:17:47 UTC Merge branch 'mh/get-remote-group-fix' into maint An off-by-one error made "git remote" to mishandle a remote with a single letter nickname. * mh/get-remote-group-fix: get_remote_group(): use skip_prefix() get_remote_group(): eliminate superfluous call to strcspn() get_remote_group(): rename local variable "space" to "wordlen" get_remote_group(): handle remotes with single-character names 04 September 2015, 02:17:48 UTC
5c99995 Christian Couder 30 August 2015, 19:14:40 UTC trailer: support multiline title We currently ignore the first line passed to `git interpret-trailers`, when looking for the beginning of the trailers. Unfortunately this does not work well when a commit is created with a line break in the title, using for example the following command: git commit -m 'place of code: change we made' That's why instead of ignoring only the first line, it is better to ignore the first paragraph. Signed-off-by: Christian Couder <christian.couder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 August 2015, 18:14:08 UTC
1733ed3 Erik Elfström 30 August 2015, 09:18:09 UTC t7300: fix broken && chains While we are here, remove some boilerplate by using test_commit. Signed-off-by: Erik Elfström <erik.elfstrom@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 August 2015, 16:46:36 UTC
ce11360 Jeff King 29 August 2015, 05:04:18 UTC log: diagnose empty HEAD more clearly If you init or clone an empty repository, the initial message from running "git log" is not very friendly: $ git init Initialized empty Git repository in /home/peff/foo/.git/ $ git log fatal: bad default revision 'HEAD' Let's detect this situation and write a more friendly message: $ git log fatal: your current branch 'master' does not have any commits yet We also detect the case that 'HEAD' points to a broken ref; this should be even less common, but is easy to see. Note that we do not diagnose all possible cases. We rely on resolve_ref, which means we do not get information about complex cases. E.g., "--default master" would use dwim_ref to find "refs/heads/master", but we notice only that "master" does not exist. Similarly, a complex sha1 expression like "--default HEAD^2" will not resolve as a ref. But that's OK. We fall back to a generic error message in those cases, and they are unlikely to be used anyway. Catching an empty or broken "HEAD" improves the common case, and the other cases are not regressed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 August 2015, 16:34:20 UTC
475a344 David Turner 27 August 2015, 17:07:54 UTC commit: don't rewrite shared index unnecessarily Remove a cache invalidation which would cause the shared index to be rewritten on as-is commits. When the cache-tree has changed, we need to update it. But we don't necessarily need to update the shared index. So setting active_cache_changed to SOMETHING_CHANGED is unnecessary. Instead, we let update_main_cache_tree just update the CACHE_TREE_CHANGED bit. In order to test this, make test-dump-split-index not segfault on missing replace_bitmap/delete_bitmap. This new codepath is not called now that the test passes, but is necessary to avoid a segfault when the new test is run with the old builtin/commit.c code. Signed-off-by: David Turner <dturner@twopensource.com> Acked-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 31 August 2015, 15:41:07 UTC
b80fa84 Alex Henrie 27 August 2015, 04:26:19 UTC git-submodule: remove extraneous space from error message Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Acked-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 August 2015, 18:57:24 UTC
c415fb7 Junio C Hamano 28 August 2015, 18:19:57 UTC Git 2.5.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 August 2015, 18:19:57 UTC
c3cb7b6 Jose F. Morales 28 August 2015, 09:43:37 UTC Mingw: verify both ends of the pipe () call The code to open and test the second end of the pipe clearly imitates the code for the first end. A little too closely, though... Let's fix the obvious copy-edit bug. Signed-off-by: Jose F. Morales <jfmcjf@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 August 2015, 18:11:50 UTC
88329ca René Scharfe 22 August 2015, 19:06:45 UTC archive-zip: support more than 65535 entries Support more than 65535 entries cleanly by writing a "zip64 end of central directory record" (with a 64-bit field for the number of entries) before the usual "end of central directory record" (which contains only a 16-bit field). InfoZIP's zip does the same. Archives with 65535 or less entries are not affected. Programs that extract all files like InfoZIP's zip and 7-Zip ignored the field and could extract all files already. Software that relies on the ZIP file directory to show a list of contained files quickly to simulate to normal directory like Windows' built-in ZIP functionality only saw a subset of the included files. Windows supports ZIP64 since Vista according to https://en.wikipedia.org/wiki/Zip_%28file_format%29#ZIP64. Suggested-by: Johannes Schauer <josch@debian.org> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 August 2015, 15:54:57 UTC
0f747f9 René Scharfe 22 August 2015, 19:06:31 UTC archive-zip: use a local variable to store the creator version Use a simpler conditional right next to the code which makes a higher creator version necessary -- namely symlink handling and support for executable files -- instead of a long line with a ternary operator. The resulting code has more lines but is simpler and allows reuse of the value easily. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 August 2015, 15:52:22 UTC
19ee294 René Scharfe 22 August 2015, 19:06:12 UTC t5004: test ZIP archives with many entries A ZIP file directory has a 16-bit field for the number of entries it contains. There are 64-bit extensions to deal with that. Demonstrate that git archive --format=zip currently doesn't use them and instead overflows the field. InfoZIP's unzip doesn't care about this field and extracts all files anyway. Software that uses the directory for presenting a filesystem like view quickly -- notably Windows -- depends on it, but doesn't lend itself to an automatic test case easily. Use InfoZIP's zipinfo, which probably isn't available everywhere but at least can provides *some* way to check this field. To speed things up a bit create and commit only a subset of the files and build a fake tree out of duplicates and pass that to git archive. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 August 2015, 15:52:10 UTC
6262fe9 Christian Couder 26 August 2015, 02:51:00 UTC trailer: retitle a test and correct an in-comment message Signed-off-by: Christian Couder <christian.couder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 26 August 2015, 19:16:56 UTC
486e1e1 Brett Randall 24 August 2015, 00:23:45 UTC git-svn doc: mention "svn-remote.<name>.include-paths" Mention the configuration variable in a way similar to how "svn-remote.<name>.ignore-paths" is mentioned. Signed-off-by: Brett Randall <javabrett@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 26 August 2015, 17:27:26 UTC
52f6893 Junio C Hamano 25 August 2015, 23:09:17 UTC Merge branch 'jk/guess-repo-name-regression-fix' into maint "git clone $URL" in recent releases of Git contains a regression in the code that invents a new repository name incorrectly based on the $URL. This has been corrected. * jk/guess-repo-name-regression-fix: clone: use computed length in guess_dir_name clone: add tests for output directory 25 August 2015, 23:09:17 UTC
84deb3e Junio C Hamano 25 August 2015, 23:09:16 UTC Merge branch 'jk/test-with-x' into maint Running tests with the "-x" option to make them verbose had some unpleasant interactions with other features of the test suite. * jk/test-with-x: test-lib: disable trace when test is not verbose test-lib: turn off "-x" tracing during chain-lint check 25 August 2015, 23:09:16 UTC
7a23807 Junio C Hamano 25 August 2015, 23:09:16 UTC Merge branch 'sb/check-return-from-read-ref' into maint * sb/check-return-from-read-ref: transport-helper: die on errors reading refs. 25 August 2015, 23:09:16 UTC
425a4c7 Junio C Hamano 25 August 2015, 23:09:15 UTC Merge branch 'mm/pull-upload-pack' into maint "git pull" in recent releases of Git has a regression in the code that allows custom path to the --upload-pack=<program>. This has been corrected. Note that this is irrelevant for 'master' with "git pull" rewritten in C. * mm/pull-upload-pack: pull: pass upload_pack only when it was given pull.sh: quote $upload_pack when passing it to git-fetch 25 August 2015, 23:09:15 UTC
13e0e28 Junio C Hamano 25 August 2015, 23:06:53 UTC pull: pass upload_pack only when it was given The upload_pack shell variable is initialized to an empty string, so conditional expansion with ${upload_pack+"$upload_pack"} would not work very well. You need a colon there. Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 August 2015, 23:08:58 UTC
82aec45 Eric Sunshine 23 August 2015, 21:31:09 UTC generate-cmdlist: re-implement as shell script 527ec39 (generate-cmdlist: parse common group commands, 2015-05-21) replaced generate-cmdlist.sh with a more functional Perl version, generate-cmdlist.perl. The Perl version gleans named tags from a new "common groups" section in command-list.txt and recognizes those tags in "command list" section entries in place of the old 'common' tag. This allows git-help to, not only recognize, but also group common commands. Although the tests require Perl, 527ec39 creates an unconditional dependence upon Perl in the build system itself, which can not be overridden with NO_PERL. Such a dependency may be undesirable; for instance, the 'git-lite' package in the FreeBSD ports tree is intended as a minimal Git installation (which may, for example, be useful on servers needing only local clone and update capability), which, historically, has not depended upon Perl[1]. Therefore, revive generate-cmdlist.sh and extend it to recognize "common groups" and its named tags. Retire generate-cmdlist.perl. [1]: http://thread.gmane.org/gmane.comp.version-control.git/275905/focus=276132 Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 August 2015, 18:24:31 UTC
82fde87 Nguyễn Thái Ngọc Duy 25 August 2015, 10:30:46 UTC setup: update the right file in multiple checkouts This code is introduced in 23af91d (prune: strategies for linked checkouts - 2014-11-30), and it's supposed to implement this rule from that commit's message: - linked checkouts are supposed to keep its location in $R/gitdir up to date. The use case is auto fixup after a manual checkout move. Note the name, "$R/gitdir", not "$R/gitfile". Correct the path to be updated accordingly. While at there, make sure I/O errors are not silently dropped. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 August 2015, 16:39:08 UTC
2aea7a5 Jeff King 23 August 2015, 17:56:40 UTC rev-list: make it obvious that we do not support notes The rev-list command does not have the internal infrastructure to display notes. Running: git rev-list --notes HEAD will silently ignore the "--notes" option. Running: git rev-list --notes --grep=. HEAD will crash on an assert. Running: git rev-list --format=%N HEAD will place a literal "%N" in the output (it does not even expand to an empty string). Let's have rev-list tell the user that it cannot fill the user's request, rather than silently producing wrong data. Likewise, let's remove mention of the notes options from the rev-list documentation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 August 2015, 17:33:15 UTC
9e9de18 Jeff King 24 August 2015, 06:11:33 UTC config: silence warnings for command names with invalid keys When we are running the git command "foo", we may have to look up the config keys "pager.foo" and "alias.foo". These config schemes are mis-designed, as the command names can be anything, but the config syntax has some restrictions. For example: $ git foo_bar error: invalid key: pager.foo_bar error: invalid key: alias.foo_bar git: 'foo_bar' is not a git command. See 'git --help'. You cannot name an alias with an underscore. And if you have an external command with one, you cannot configure its pager. In the long run, we may develop a different config scheme for these features. But in the near term (and because we'll need to support the existing scheme indefinitely), we should at least squelch the error messages shown above. These errors come from git_config_parse_key. Ideally we would pass a "quiet" flag to the config machinery, but there are many layers between the pager code and the key parsing. Passing a flag through all of those would be an invasive change. Instead, let's provide a config function to report on whether a key is syntactically valid, and have the pager and alias code skip lookup for bogus keys. We can build this easily around the existing git_config_parse_key, with two minor modifications: 1. We now handle a NULL store_key, to validate but not write out the normalized key. 2. We accept a "quiet" flag to avoid writing to stderr. This doesn't need to be a full-blown public "flags" field, because we can make the existing implementation a static helper function, keeping the mess contained inside config.c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 24 August 2015, 15:52:23 UTC
7aa9b9b SZEDER Gábor 20 August 2015, 14:06:27 UTC wt-status: move #include "pathspec.h" to the header The declaration of 'struct wt_status' requires the declararion of 'struct pathspec'. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2015, 21:49:27 UTC
dc5d553 Christian Couder 20 August 2015, 21:59:15 UTC trailer: ignore first line of message When looking for the start of the trailers in the message we are passed, we should ignore the first line of the message. The reason is that if we are passed a patch or commit message then the first line should be the patch title. If we are passed only trailers we can expect that they start with an empty line that can be ignored too. This way we can properly process commit messages that have only one line with something that looks like a trailer, for example like "area of code: change we made". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2015, 17:17:47 UTC
f04c690 Andreas Schwab 21 August 2015, 15:06:18 UTC Documentation/config: fix inconsistent label on gc.*.reflogExpireUnreachable Change <ref> to <pattern> in the description of gc.*.reflogExpireUnreachable, since that is what the text refers to. Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 August 2015, 17:15:13 UTC
1269847 SZEDER Gábor 20 August 2015, 13:58:55 UTC t3020: fix typo in test description Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 August 2015, 20:14:21 UTC
8b54c23 Junio C Hamano 20 August 2015, 16:57:32 UTC ps_matched: xcalloc() takes nmemb and then element size Even though multiplication is commutative, the order of arguments should be xcalloc(nmemb, size). ps_matched is an array of 1-byte element whose size is the same as the number of pathspec elements. Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 August 2015, 16:57:38 UTC
552a736 Junio C Hamano 19 August 2015, 21:26:31 UTC Start preparing for 2.5.1 Signed-off-by: Junio C Hamano <gitster@pobox.com> 19 August 2015, 21:48:13 UTC
91db009 Junio C Hamano 19 August 2015, 21:41:34 UTC Merge branch 'ta/docfix-index-format-tech' into maint * ta/docfix-index-format-tech: typofix for index-format.txt 19 August 2015, 21:41:34 UTC
b994b9b Junio C Hamano 19 August 2015, 21:41:33 UTC Merge branch 'sb/parse-options-codeformat' into maint * sb/parse-options-codeformat: parse-options: align curly braces for all options 19 August 2015, 21:41:34 UTC
223b55a Junio C Hamano 19 August 2015, 21:41:33 UTC Merge branch 'sb/remove-unused-var-from-builtin-add' into maint * sb/remove-unused-var-from-builtin-add: add: remove dead code 19 August 2015, 21:41:33 UTC
24493ff Junio C Hamano 19 August 2015, 21:41:32 UTC Merge branch 'kn/tag-doc-fix' into maint * kn/tag-doc-fix: Documentation/tag: remove double occurance of "<pattern>" 19 August 2015, 21:41:32 UTC
cacee08 Junio C Hamano 19 August 2015, 21:41:31 UTC Merge branch 'es/doc-clean-outdated-tools' into maint * es/doc-clean-outdated-tools: Documentation/git-tools: retire manually-maintained list Documentation/git-tools: drop references to defunct tools Documentation/git-tools: fix item text formatting Documentation/git-tools: improve discoverability of Git wiki Documentation/git: drop outdated Cogito reference 19 August 2015, 21:41:31 UTC
25a294e Junio C Hamano 19 August 2015, 21:41:30 UTC Merge branch 'nd/export-worktree' into maint Running an aliased command from a subdirectory when the .git thing in the working tree is a gitfile pointing elsewhere did not work. * nd/export-worktree: setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR 19 August 2015, 21:41:30 UTC
f9610bc Junio C Hamano 19 August 2015, 21:41:29 UTC Merge branch 'mh/fast-import-optimize-current-from' into maint Often a fast-import stream builds a new commit on top of the previous commit it built, and it often unconditionally emits a "from" command to specify the first parent, which can be omitted in such a case. This caused fast-import to forget the tree of the previous commit and then re-read it from scratch, which was inefficient. Optimize for this common case. * mh/fast-import-optimize-current-from: fast-import: do less work when given "from" matches current branch head 19 August 2015, 21:41:29 UTC
back to top