- 17 4月, 2017 8 次提交
-
-
由 Junio C Hamano 提交于
Update the build dependency so that an update to /usr/bin/perl etc. result in recomputation of perl.mak file. * ab/regen-perl-mak-with-different-perl: perl: regenerate perl.mak if perl -V changes
-
由 Junio C Hamano 提交于
"git diff --submodule=diff" learned to work better in a project with a submodule that in turn has its own submodules. * sb/show-diff-for-submodule-in-diff-fix: diff: submodule inline diff to initialize env array.
-
由 Junio C Hamano 提交于
Doc update. * qp/bisect-docfix: git-bisect.txt: add missing word
-
由 Junio C Hamano 提交于
Doc update. * mm/ls-files-s-doc: Documentation: document elements in "ls-files -s" output in order
-
由 Junio C Hamano 提交于
Update error handling for codepath that deals with corrupt loose objects. * jk/loose-object-info-report-error: index-pack: detect local corruption in collision check sha1_loose_object_info: return error for corrupted objects
-
由 Junio C Hamano 提交于
Code cleanup. * jc/bs-t-is-not-a-tab-for-sed: contrib/git-resurrect.sh: do not write \t for HT in sed scripts
-
由 Junio C Hamano 提交于
Code cleanup. * jc/unused-symbols: remote.[ch]: parse_push_cas_option() can be static
-
由 Junio C Hamano 提交于
Code clean-up. * jk/snprintf-cleanups: daemon: use an argv_array to exec children gc: replace local buffer with git_path transport-helper: replace checked snprintf with xsnprintf convert unchecked snprintf into xsnprintf combine-diff: replace malloc/snprintf with xstrfmt replace unchecked snprintf calls with heap buffers receive-pack: print --pack-header directly into argv array name-rev: replace static buffer with strbuf create_branch: use xstrfmt for reflog message create_branch: move msg setup closer to point of use avoid using mksnpath for refs avoid using fixed PATH_MAX buffers for refs fetch: use heap buffer to format reflog tag: use strbuf to format tag header diff: avoid fixed-size buffer for patch-ids odb_mkstemp: use git_path_buf odb_mkstemp: write filename into strbuf do not check odb_mkstemp return value for errors
-
- 11 4月, 2017 5 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Define a new task in .travis.yml that triggers a test session on Windows run elsewhere. * ls/travis-relays-for-windows-ci: travis-ci: build and test Git on Windows
-
由 Junio C Hamano 提交于
Code cleanup. * cc/untracked: update-index: fix xgetcwd() related memory leak
-
由 Junio C Hamano 提交于
The default behaviour of "git log" in an interactive session has been changed to enable "--decorate". * ah/log-decorate-default-to-auto: log: if --decorate is not given, default to --decorate=auto
-
由 Junio C Hamano 提交于
"git tag/branch/for-each-ref" family of commands long allowed to filter the refs by "--contains X" (show only the refs that are descendants of X), "--merged X" (show only the refs that are ancestors of X), "--no-merged X" (show only the refs that are not ancestors of X). One curious omission, "--no-contains X" (show only the refs that are not descendants of X) has been added to them. * ab/ref-filter-no-contains: tag: add tests for --with and --without ref-filter: reflow recently changed branch/tag/for-each-ref docs ref-filter: add --no-contains option to tag/branch/for-each-ref tag: change --point-at to default to HEAD tag: implicitly supply --list given another list-like option tag: change misleading --list <pattern> documentation parse-options: add OPT_NONEG to the "contains" option tag: add more incompatibles mode tests for-each-ref: partly change <object> to <commit> in help tag tests: fix a typo in a test description tag: remove a TODO item from the test suite ref-filter: add test for --contains on a non-commit ref-filter: make combining --merged & --no-merged an error tag doc: reword --[no-]merged to talk about commits, not tips tag doc: split up the --[no-]merged documentation tag doc: move the description of --[no-]merged earlier
-
- 03 4月, 2017 1 次提交
-
-
由 Stefan Beller 提交于
David reported: > When I try to run `git diff --submodule=diff` in a submodule which has > it's own submodules that have changes I get the error: fatal: bad > object. This happens, because we do not properly initialize the environment in which the diff is run in the submodule. That means we inherit the environment from the main process, which sets environment variables. (Apparently we do set environment variables which we do not set when not in a submodules, i.e. the .git directory is linked) This commit, just like fd47ae6a (diff: teach diff to display submodule difference with an inline diff, 2016-08-31) introduces bad test code (i.e. hard coded hash values), which will be cleanup up in a later patch. Reported-by: NDavid Parrish <daveparrish@gmail.com> Signed-off-by: NStefan Beller <sbeller@google.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 4月, 2017 4 次提交
-
-
由 Quentin Pradet 提交于
Signed-off-by: NQuentin Pradet <quentin.pradet@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Mostyn Bramley-Moore 提交于
List the fields in order of appearance in the command output. Signed-off-by: NMostyn Bramley-Moore <mostyn@antipode.se> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
When we notice that we have a local copy of an incoming object, we compare the two objects to make sure we haven't found a collision. Before we get to the actual object bytes, though, we compare the type and size from sha1_object_info(). If our local object is corrupted, then the type will be OBJ_BAD, which obviously will not match the incoming type, and we'll report "SHA1 COLLISION FOUND" (with capital letters and everything). This is confusing, as the problem is not a collision but rather local corruption. We should report that instead (just like we do if reading the rest of the object content fails a few lines later). Note that we _could_ just ignore the error and mark it as a non-collision. That would let you "git fetch" to replace a corrupted object. But it's not a very reliable method for repairing a repository. The earlier want/have negotiation tries to get the other side to omit objects we already have, and it would not realize that we are "missing" this corrupted object. So we're better off complaining loudly when we see corruption, and letting the user take more drastic measures to repair (like making a full clone elsewhere and copying the pack into place). Note that the test sets transfer.unpackLimit in the receiving repository so that we use index-pack (which is what does the collision check). Normally for such a small push we'd use unpack-objects, which would simply try to write the loose object, and discard the new one when we see that there's already an old one. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jeff King 提交于
When sha1_loose_object_info() finds that a loose object file cannot be stat(2)ed or mmap(2)ed, it returns -1 to signal an error to the caller. However, if it found that the loose object file is corrupt and the object data cannot be used from it, it stuffs OBJ_BAD into "type" field of the object_info, but returns zero (i.e., success), which can confuse callers. This is due to 052fe5ea (sha1_loose_object_info: make type lookup optional, 2013-07-12), which switched the return to a strict success/error, rather than returning the type (but botched the return). Callers of regular sha1_object_info() don't notice the difference, as that function returns the type (which is OBJ_BAD in this case). However, direct callers of sha1_object_info_extended() see the function return success, but without setting any meaningful values in the object_info struct, leading them to access potentially uninitialized memory. The easiest way to see the bug is via "cat-file -s", which will happily ignore the corruption and report whatever value happened to be in the "size" variable. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 4月, 2017 2 次提交
-
-
由 Junio C Hamano 提交于
Just like we did in 0d1d6e50 ("t/t7003: replace \t with literal tab in sed expression", 2010-08-12), avoid writing "\t" for HT in sed scripts, which is not portable. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Since 068c77a5 ("builtin/send-pack.c: use parse_options API", 2015-08-19), there is no external user of this helper function. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 31 3月, 2017 20 次提交
-
-
由 Jeff King 提交于
Our struct child_process already has its own argv_array. Let's use that to avoid having to format options into separate buffers. Note that we'll need to declare the child process outside of the run_service_command() helper to do this. But that opens up a further simplification, which is that the helper can append to our argument list, saving each caller from specifying "." manually. Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
We probe the "17/" loose object directory for auto-gc, and use a local buffer to format the path. We can just use git_path() for this. It handles paths of any length (reducing our error handling). And because we feed the result straight to a system call, we can just use the static variant. Note that git_path also knows the string "objects/" is special, and will replace it with git_object_directory() when necessary. Another alternative would be to use sha1_file_name() for the pretend object "170000...", but that ends up being more hassle for no gain, as we have to truncate the final path component. Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
We can use xsnprintf to do our truncation check with less code. The error message isn't as specific, but the point is that this isn't supposed to trigger in the first place (because our buffer is big enough to handle any int). Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
These calls to snprintf should always succeed, because their input is small and fixed. Let's use xsnprintf to make sure this is the case (and to make auditing for actual truncation easier). These could be candidates for turning into heap buffers, but they fall into a few broad categories that make it not worth doing: - formatting single numbers is simple enough that we can see the result should fit - the size of a sha1 is likewise well-known, and I didn't want to cause unnecessary conflicts with the ongoing process to convert these constants to GIT_MAX_HEXSZ - the interface for curl_errorstr is dictated by curl Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
There's no need to use the magic "100" when a strbuf can do it for us. Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
We'd prefer to avoid unchecked snprintf calls because truncation can lead to unexpected results. These are all cases where truncation shouldn't ever happen, because the input to snprintf is fixed in size. That makes them candidates for xsnprintf(), but it's simpler still to just use the heap, and then nobody has to wonder if "100" is big enough. We'll use xstrfmt() where possible, and a strbuf when we need the resulting size or to reuse the same buffer in a loop. Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
After receive-pack reads the pack header from the client, it feeds the already-read part to index-pack and unpack-objects via their --pack-header command-line options. To do so, we format it into a fixed buffer, then duplicate it into the child's argv_array. Our buffer is long enough to handle any possible input, so this isn't wrong. But it's more complicated than it needs to be; we can just argv_array_pushf() the final value and avoid the intermediate copy. This drops the magic number and is more efficient, too. Note that we need to push to the argv_array in order, which means we can't do the push until we are in the "unpack-objects versus index-pack" conditional. Rather than duplicate the slightly complicated format specifier, I pushed it into a helper function. Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
When name-rev needs to format an actual name, we do so into a fixed-size buffer. That includes the actual ref tip, as well as any traversal information. Since refs can exceed 1024 bytes, this means you can get a bogus result. E.g., doing: git tag $(perl -e 'print join("/", 1..1024)') git describe --contains HEAD^ results in ".../282/283", when it should be ".../1023/1024~1". We can solve this by using a heap buffer. We'll use a strbuf, which lets us write into the same buffer from our loop without having to reallocate. Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
We generate a reflog message that contains some fixed text plus a branch name, and use a buffer of size PATH_MAX + 20. This mostly works if you assume that refnames are shorter than PATH_MAX, but: 1. That's not necessarily true. PATH_MAX is not always the filesystem's limit. 2. The "20" is not sufficiently large for the fixed text anyway. Let's just switch to a heap buffer so we don't have to even care. Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
In create_branch() we write the reflog msg into a buffer in the main function, but then use it only inside a conditional. If you carefully follow the logic, you can confirm that we never use the buffer uninitialized nor write when it would not be used. But we can make this a lot more obvious by simply moving the write step inside the conditional. Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
Like the previous commit, we'd like to avoid the assumption that refs fit into PATH_MAX-sized buffers. These callsites have an extra twist, though: they write the refnames using mksnpath. This does two things beyond a regular snprintf: 1. It quietly writes "/bad-path/" when truncation occurs. This saves the caller having to check the error code, but if you aren't actually feeding the result to a system call (and we aren't here), it's questionable. 2. It calls cleanup_path(), which removes leading instances of "./". That's questionable when dealing with refnames, as we could silently canonicalize a syntactically bogus refname into a valid one. Let's convert each case to use a strbuf. This is preferable to xstrfmt() because we can reuse the same buffer as we loop. Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
Many functions which handle refs use a PATH_MAX-sized buffer to do so. This is mostly reasonable as we have to write loose refs into the filesystem, and at least on Linux the 4K PATH_MAX is big enough that nobody would care. But: 1. The static PATH_MAX is not always the filesystem limit. 2. On other platforms, PATH_MAX may be much smaller. 3. As we move to alternate ref storage, we won't be bound by filesystem limits. Let's convert these to heap buffers so we don't have to worry about truncation or size limits. We may want to eventually constrain ref lengths for sanity and to prevent malicious names, but we should do so consistently across all platforms, and in a central place (like the ref code). Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
Part of the reflog content comes from the environment, which can be much larger than our fixed buffer. Let's use a heap buffer so we avoid truncating it. Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
We format the tag header into a fixed 1024-byte buffer. But since the tag-name and tagger ident can be arbitrarily large, we may unceremoniously die with "tag header too big". Let's just use a strbuf instead. Note that it looks at first glance like we can just format this directly into the "buf" strbuf where it will ultimately go. But that buffer may already contain the tag message, and we have no easy way to prepend formatted data to a strbuf (we can only splice in an already-generated buffer). This isn't a performance-critical path, so going through an extra buffer isn't a big deal. Signed-off-by: NJeff King <peff@peff.net>
-
由 Jeff King 提交于
To generate a patch id, we format the diff header into a fixed-size buffer, and then feed the result to our sha1 computation. The fixed buffer has size '4*PATH_MAX + 20', which in theory accommodates the four filenames plus some extra data. Except: 1. The filenames may not be constrained to PATH_MAX. The static value may not be a real limit on the current filesystem. Moreover, we may compute patch-ids for names stored only in git, without touching the current filesystem at all. 2. The 20 bytes is not nearly enough to cover the extra content we put in the buffer. As a result, the data we feed to the sha1 computation may be truncated, and it's possible that a commit with a very long filename could erroneously collide in the patch-id space with another commit. For instance, if one commit modified "really-long-filename/foo" and another modified "bar" in the same directory. In practice this is unlikely. Because the filenames are repeated, and because there's a single cutoff at the end of the buffer, the offending filename would have to be on the order of four times larger than PATH_MAX. We could fix this by moving to a strbuf. However, we can observe that the purpose of formatting this in the first place is to feed it to git_SHA1_Update(). So instead, let's just feed each part of the formatted string directly. This actually ends up more readable, and we can even factor out some duplicated bits from the various conditional branches. Technically this may change the output of patch-id for very long filenames, but it's not worth making an exception for this in the --stable output. It was a bug, and one that only affected an unlikely set of paths. And anyway, the exact value would have varied from platform to platform depending on the value of PATH_MAX, so there is no "stable" value. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
Build fix. * jk/make-coccicheck-detect-errors: Makefile: detect errors in running spatch
-
由 Junio C Hamano 提交于
"git receive-pack" could have been forced to die by attempting allocate an unreasonably large amount of memory with a crafted push certificate; this has been fixed. * bc/push-cert-receive-fix: builtin/receive-pack: fix incorrect pointer arithmetic
-
由 Junio C Hamano 提交于
Removing an entry from a notes tree and then looking another note entry from the resulting tree using the internal notes API functions did not work as expected. No in-tree users of the API has such access pattern, but it still is worth fixing. * mh/notes-tree-consolidate-fix: notes: do not break note_tree structure in note_tree_consolidate()
-
由 Junio C Hamano 提交于
A recent update to "rebase -i" stopped running hooks for the "git commit" command during "reword" action, which has been fixed. * js/rebase-i-reword-to-run-hooks: sequencer: allow the commit-msg hooks to run during a `reword` sequencer: make commit options more extensible t7504: document regression: reword no longer calls commit-msg
-