- 14 6月, 2014 9 次提交
-
-
由 Jeff King 提交于
This will make it easier to manage the buffer cache independently of the "struct commit" objects. It also shrinks "struct commit" by one pointer, which may be helpful. Unfortunately it does not reduce the max memory size of something like "rev-list", because rev-list uses get_cached_commit_buffer() to decide not to show each commit's output (and due to the design of slab_at, accessing the slab requires us to extend it, allocating exactly the same number of buffer pointers we dropped from the commit structs). Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Callers currently must use init_foo_slab() at runtime before accessing a slab. For global slabs, it's much nicer if we can initialize them in BSS, so that each user does not have to add code to check-and-initialize. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Each of these sites assumes that commit->buffer is valid. Since they would segfault if this was not the case, they are likely to be correct in practice. However, we can future-proof them by using get_commit_buffer. And as a side effect, we abstract away the final bare uses of commit->buffer. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Like the callsites in the previous commit, logmsg_reencode already falls back to read_sha1_file when necessary. However, I split its conversion out into its own commit because it's a bit more complex. We return either: 1. The original commit->buffer 2. A newly allocated buffer from read_sha1_file 3. A reencoded buffer (based on either 1 or 2 above). while trying to do as few extra reads/allocations as possible. Callers currently free the result with logmsg_free, but we can simplify this by pointing them straight to unuse_commit_buffer. This is a slight layering violation, in that we may be passing a buffer from (3). However, since the end result is to free() anything except (1), which is unlikely to change, and because this makes the interface much simpler, it's a reasonable bending of the rules. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
For both of these sites, we already do the "fallback to read_sha1_file" trick. But we can shorten the code by just using get_commit_buffer. Note that the error cases are slightly different when read_sha1_file fails. get_commit_buffer will die() if the object cannot be loaded, or is a non-commit. For get_sha1_oneline, this will almost certainly never happen, as we will have just called parse_object (and if it does, it's probably worth complaining about). For record_author_date, the new behavior is probably better; we notify the user of the error instead of silently ignoring it. And because it's used only for sorting by author-date, somebody examining a corrupt repo can fallback to the regular traversal order. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Some call sites check commit->buffer to see whether we have a cached buffer, and if so, do some work with it. In the long run we may want to switch these code paths to make their decision on a different boolean flag (because checking the cache may get a little more expensive in the future). But for now, we can easily support them by converting the calls to use get_cached_commit_buffer. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Many sites look at commit->buffer to get more detailed information than what is in the parsed commit struct. However, we sometimes drop commit->buffer to save memory, in which case the caller would need to read the object afresh. Some callers do this (leading to duplicated code), and others do not (which opens the possibility of a segfault if somebody else frees the buffer). Let's provide a pair of helpers, "get" and "unuse", that let callers easily get the buffer. They will use the cached buffer when possible, and otherwise load from disk using read_sha1_file. Note that we also need to add a "get_cached" variant which returns NULL when we do not have a cached buffer. At first glance this seems to defeat the purpose of "get", which is to always provide a return value. However, some log code paths actually use the NULL-ness of commit->buffer as a boolean flag to decide whether to try printing the commit. At least for now, we want to continue supporting that use. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Right now this is just a one-liner, but abstracting it will make it easier to change later. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
This converts two lines into one at each caller. But more importantly, it abstracts the concept of freeing the buffer, which will make it easier to change later. Note that we also need to provide a "detach" mechanism for a tricky case in index-pack. We are passed a buffer for the object generated by processing the incoming pack. If we are not using --strict, we just calculate the sha1 on that buffer and return, leaving the caller to free it. But if we are using --strict, we actually attach that buffer to an object, pass the object to the fsck functions, and then detach the buffer from the object again (so that the caller can free it as usual). In this case, we don't want to free the buffer ourselves, but just make sure it is no longer associated with the commit. Note that we are making the assumption here that the attach/detach process does not impact the buffer at all (e.g., it is never reallocated or modified). That holds true now, and we have no plans to change that. However, as we abstract the commit_buffer code, this dependency becomes less obvious. So when we detach, let's also make sure that we get back the same buffer that we gave to the commit_buffer code. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 6月, 2014 7 次提交
-
-
由 Jeff King 提交于
This simplifies the code, as logmsg_reencode handles the reencoding for us in a single call. It also means we learn logmsg_reencode's trick of pulling the buffer from disk when commit->buffer is NULL (we currently just silently return!). It is doubtful this matters in practice, though, as sequencer operations would not generally turn off save_commit_buffer. Note that we may be fixing a bug here. The existing code does: if (same_encoding(to, from)) reencode_string(buf, to, from); That probably should have been "!same_encoding". Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
The return value from logmsg_reencode may be either a newly allocated buffer or a pointer to the existing commit->buffer. We would not want the caller to accidentally free() or modify the latter, so let's mark it as const. We can cast away the constness in logmsg_free, but only once we have determined that it is a free-able buffer. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
In both blame and merge-recursive, we sometimes create a "fake" commit struct for convenience (e.g., to represent the HEAD state as if we would commit it). By allocating ourselves rather than using alloc_commit_node, we do not properly set the "index" field of the commit. This can produce subtle bugs if we then use commit-slab on the resulting commit, as we will share the "0" index with another commit. We can fix this by using alloc_commit_node() to allocate. Note that we cannot free the result, as it is part of our commit allocator. However, both cases were already leaking the allocated commit anyway, so there's nothing to fix up. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
Whenever we create a commit object via lookup_commit, we give it a unique index to be used with the commit-slab API. The theory is that any "struct commit" we create would follow this code path, so any such struct would get an index. However, callers could use alloc_commit_node() directly (and get multiple commits with index 0). Let's push the indexing into alloc_commit_node so that it's hard for callers to get it wrong. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
When 2c1cbec1 (Use proper object allocators for unknown object nodes too, 2007-04-16), added a special "any_object" allocator, it never taught alloc_report to report on it. To do so we need to add an extra type argument to the REPORT macro, as that commit did for DEFINE_ALLOCATOR. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
It is not a good idea to strbuf_attach an arbitrary pointer just because a function you are calling wants a strbuf. Attaching implies a transfer of memory ownership; if anyone were to modify or release the resulting strbuf, we would free() the pointer, leading to possible problems: 1. Other users of the original pointer might access freed memory. 2. The pointer might not be the start of a malloc'd area, so calling free() on it in the first place would be wrong. In the two cases modified here, we are fortunate that nobody touches the strbuf once it is attached, but it is an accident waiting to happen. Since the previous commit, commit_tree and friends take a pointer/buf pair, so we can just do away with the strbufs entirely. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
While strbufs are pretty common throughout our code, it is more flexible for functions to take a pointer/len pair than a strbuf. It's easy to turn a strbuf into such a pair (by dereferencing its members), but less easy to go the other way (you can strbuf_attach, but that has implications about memory ownership). This patch teaches commit_tree (and its associated callers and sub-functions) to take such a pair for the commit message rather than a strbuf. This makes passing the buffer around slightly more verbose, but means we can get rid of some dangerous strbuf_attach calls in the next patch. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 31 5月, 2014 3 次提交
-
-
由 Junio C Hamano 提交于
-
由 Junio C Hamano 提交于
This is expected to be the final maintenance release for 1.9 series, merging the remaining fixes that are relevant and are already in 2.0. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
These were originally removed by 0232852b (t5537: move http tests out to t5539, 2014-02-13). However, they were accidentally re-added in 1ddb4d7e (Merge branch 'nd/upload-pack-shallow', 2014-03-21). This looks like an error in manual conflict resolution. Here's what happened: 1. v1.9.0 shipped with the http tests in t5537. 2. We realized that this caused problems, and built 0232852b on top to move the tests to their own file. This fix made it into v1.9.1. 3. We later had another fix in nd/upload-pack-shallow that also touched t5537. It was built directly on v1.9.0. When we merged nd/upload-pack-shallow to master, we got a conflict; it was built on a version with the http tests, but we had since removed them. The correct resolution was to drop the http tests and keep the new ones, but instead we kept everything. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 5月, 2014 3 次提交
-
-
由 Junio C Hamano 提交于
* rh/prompt-pcmode-avoid-eval-on-refname: git-prompt.sh: don't assume the shell expands the value of PS1
-
由 Junio C Hamano 提交于
* mw/symlinks: setup: fix windows path buffer over-stepping setup: don't dereference in-tree symlinks for absolute paths setup: add abspath_part_inside_repo() function t0060: add tests for prefix_path when path begins with work tree t0060: add test for prefix_path when path == work tree t0060: add test for prefix_path on symlinks via absolute paths t3004: add test for ls-files on symlinks via absolute paths
-
由 Junio C Hamano 提交于
-
- 22 5月, 2014 1 次提交
-
-
由 Junio C Hamano 提交于
Hopefully for the last time ;-) Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 21 5月, 2014 3 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jason St. John 提交于
RelNotes/2.0.0.txt: Fix several grammar issues, notably a lack of hyphens, double quotes, or articles Signed-off-by: NJason St. John <jstjohn@purdue.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Instead of showing a warning and working as before, fail and show the message and force immediate upgrade from their upstream repositories when these tools are run, per request from their primary author. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 5月, 2014 12 次提交
-
-
由 Junio C Hamano 提交于
* 'jc/graduate-remote-hg-bzr' (early part): remote-helpers: point at their upstream repositories contrib: remote-helpers: add move warnings (v2.0) Revert "Merge branch 'fc/transport-helper-sync-error-fix'"
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Felipe Contreras 提交于
The tools are now maintained out-of-tree, and they have a regression in v2.0. It's better to start warning the users as soon as possible. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
This reverts commit d508e4a8, reversing changes made to e4255213. The author of the original topic says he broke the upcoming 2.0 release with something that relates to "synchronization crash regression" while refusing to give further specifics, so this would unfortunately be the safest option for the upcoming release. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* rh/prompt-pcmode-avoid-eval-on-refname: git-prompt.sh: don't assume the shell expands the value of PS1
-
由 Richard Hansen 提交于
Not all shells subject the prompt string to parameter expansion. Test whether the shell will expand the value of PS1, and use the result to control whether raw ref names are included directly in PS1. This fixes a regression introduced in commit 8976500c ("git-prompt.sh: don't put unsanitized branch names in $PS1"): zsh does not expand PS1 by default, but that commit assumed it did. The bug resulted in prompts containing the literal string '${__git_ps1_branch_name}' instead of the actual branch name. Reported-by: NCaleb Thompson <caleb@calebthompson.io> Signed-off-by: NRichard Hansen <rhansen@bbn.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
* lt/request-pull: request-pull: resurrect for-linus -> tags/for-linus DWIM
-
由 Junio C Hamano 提交于
* jl/use-vsatisfy-correctly-for-2.0: git-gui: tolerate major version changes when comparing the git version
-
git://github.com/git-l10n/git-po由 Junio C Hamano 提交于
* git://github.com/git-l10n/git-po: fr: a lot of good fixups
-
由 Junio C Hamano 提交于
* kb/fast-hashmap: Documentation/technical/api-hashmap: remove source highlighting
-
由 Anders Kaseorg 提交于
The highlighting was pretty, but unfortunately, the failure mode when source-highlight is not installed was that the entire code block disappears. See https://bugs.debian.org/745591, https://bugs.launchpad.net/bugs/1316810. Signed-off-by: NAnders Kaseorg <andersk@mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jens Lehmann 提交于
Since git 2.0.0 starting git gui in a submodule using a gitfile fails with the following error: No working directory ../../../<path> couldn't change working directory to "../../../<path>": no such file or directory This is because "git rev-parse --show-toplevel" is only run when git gui sees a git version of at least 1.7.0 (which is the version in which the --show-toplevel option was introduced). But "package vsatisfies" returns false when the major version changes, which is not what we want here. Fix that for both places where the git version is checked using vsatisfies by appending a '-' to the version number. This tells vsatisfies that a change of the major version is not considered to be a problem, as long as the new major version is larger. This is done for both the place that caused the reported bug and another spot where the git version is tested for another feature. Reported-by: NChris Packham <judge.packham@gmail.com> Reported-by: NYann Dirson <ydirson@free.fr> Helped-by: NPat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de> Tested-by: NChris Packham <judge.packham@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 5月, 2014 1 次提交
-
-
由 Grégoire Paris 提交于
Signed-off-by: NGrégoire Paris <postmaster@greg0ire.fr> Acked-by: NJean-Noel Avila <jn.avila@free.fr>
-
- 17 5月, 2014 1 次提交
-
-
由 Junio C Hamano 提交于
Older versions of Git before v1.7.10 did not DWIM $ git pull $URL for-linus to the tag "tags/for-linus" and the users were required to say $ git pull $URL tags/for-linus instead. Because newer versions of Git works either way, request-pull used to show tags/for-linus when asked $ git request-pull origin/master $URL for-linus The recent updates broke this and in the output we see "for-linus" without the "tags/" prefix. As v1.7.10 is more than 2 years old, this should matter very little in practice, but resurrecting it is very simple. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-