summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)Author
2015-04-13grep: correctly initialize help-all optionPatrick Steinhardt
The "help-all" option is being initialized with a wrong value. While being semantically wrong this can also cause a segmentation fault in gcc on ARMv7 hardfloat platforms with a hardened toolchain. Fix this by initializing with a NULL value. Signed-off-by: Patrick Steinhardt <ps@pks.im> Reviewed-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-28diff-tree: avoid lookup_unknown_objectJeff King
We generally want to avoid lookup_unknown_object, because it results in allocating more memory for the object than may be strictly necessary. In this case, it is used to check whether we have an already-parsed object before calling parse_object, to save us from reading the object from disk. Using lookup_object would be fine for that purpose, but we can take it a step further. Since this code was written, parse_object already learned the "check lookup_object" optimization, so we can simply call parse_object directly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-28move setting of object->type to alloc_* functionsJeff King
The "struct object" type implements basic object polymorphism. Individual instances are allocated as concrete types (or as a union type that can store any object), and a "struct object *" can be cast into its real type after examining its "type" enum. This means it is dangerous to have a type field that does not match the allocation (e.g., setting the type field of a "struct blob" to "OBJ_COMMIT" would mean that a reader might read past the allocated memory). In most of the current code this is not a problem; the first thing we do after allocating an object is usually to set its type field by passing it to create_object. However, the virtual commits we create in merge-recursive.c do not ever get their type set. This does not seem to have caused problems in practice, though (presumably because we always pass around a "struct commit" pointer and never even look at the type). We can fix this oversight and also make it harder for future code to get it wrong by setting the type directly in the object allocation functions. This will also make it easier to fix problems with commit index allocation, as we know that any object allocated by alloc_commit_node will meet the invariant that an object with an OBJ_COMMIT type field will have a unique index number. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-22Merge branch 'bg/xcalloc-nmemb-then-size' into maintJunio C Hamano
* bg/xcalloc-nmemb-then-size: transport-helper.c: rearrange xcalloc arguments remote.c: rearrange xcalloc arguments reflog-walk.c: rearrange xcalloc arguments pack-revindex.c: rearrange xcalloc arguments notes.c: rearrange xcalloc arguments imap-send.c: rearrange xcalloc arguments http-push.c: rearrange xcalloc arguments diff.c: rearrange xcalloc arguments config.c: rearrange xcalloc arguments commit.c: rearrange xcalloc arguments builtin/remote.c: rearrange xcalloc arguments builtin/ls-remote.c: rearrange xcalloc arguments
2014-07-21use xmemdupz() to allocate copies of strings given by start and lengthRené Scharfe
Use xmemdupz() to allocate the memory, copy the data and make sure to NUL-terminate the result, all in one step. The resulting code is shorter, doesn't contain the constants 1 and '\0', and avoids duplicating function parameters. For blame, the last copied byte (o->file.ptr[o->file.size]) is always set to NUL by fake_working_tree_commit() or read_sha1_file(), so no information is lost by the conversion to using xmemdupz(). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-21use xcalloc() to allocate zero-initialized memoryRené Scharfe
Use xcalloc() instead of xmalloc() followed by memset() to allocate and zero out memory because it's shorter and avoids duplicating the function parameters. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-16Merge branch 'jc/fix-clone-single-starting-at-a-tag' into maintJunio C Hamano
"git clone -b brefs/tags/bar" would have mistakenly thought we were following a single tag, even though it was a name of the branch, because it incorrectly used strstr(). * jc/fix-clone-single-starting-at-a-tag: builtin/clone.c: detect a clone starting at a tag correctly
2014-07-16Merge branch 'jk/commit-buffer-length' into maintJunio C Hamano
A handful of code paths had to read the commit object more than once when showing header fields that are usually not parsed. The internal data structure to keep track of the contents of the commit object has been updated to reduce the need for this double-reading, and to allow the caller find the length of the object. * jk/commit-buffer-length: reuse cached commit buffer when parsing signatures commit: record buffer length in cache commit: convert commit->buffer to a slab commit-slab: provide a static initializer use get_commit_buffer everywhere convert logmsg_reencode to get_commit_buffer use get_commit_buffer to avoid duplicate code use get_cached_commit_buffer where appropriate provide helpers to access the commit buffer provide a helper to set the commit buffer provide a helper to free commit buffer sequencer: use logmsg_reencode in get_message logmsg_reencode: return const buffer do not create "struct commit" with xcalloc commit: push commit_index update into alloc_commit_node alloc: include any-object allocations in alloc_report replace dangerous uses of strbuf_attach commit_tree: take a pointer/len pair rather than a const strbuf
2014-07-16Merge branch 'maint-1.9' into maintJunio C Hamano
* maint-1.9: annotate: use argv_array
2014-07-16Merge branch 'maint-1.8.5' into maint-1.9Junio C Hamano
* maint-1.8.5: annotate: use argv_array t7300: repair filesystem permissions with test_when_finished enums: remove trailing ',' after last item in enum
2014-07-16annotate: use argv_arrayRené Scharfe
Simplify the code and get rid of some magic constants by using argv_array to build the argument list for cmd_blame. Be lazy and let the OS release our allocated memory, as before. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-10Merge branch 'jk/repack-pack-keep-objects' into maintJunio C Hamano
* jk/repack-pack-keep-objects: repack: s/write_bitmap/&s/ in code repack: respect pack.writebitmaps repack: do not accidentally pack kept objects by default
2014-07-02Merge branch 'maint-1.8.5' into maintJunio C Hamano
* maint-1.8.5: t7300: repair filesystem permissions with test_when_finished enums: remove trailing ',' after last item in enum
2014-07-02enums: remove trailing ',' after last item in enumRonnie Sahlberg
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-25Merge branch 'jl/status-added-submodule-is-never-ignored' into maintJunio C Hamano
"git status" (and "git commit") behaved as if changes in a modified submodule are not there if submodule.*.ignore configuration is set, which was misleading. The configuration is only to unclutter diff output during the course of development, and should not to hide changes in the "status" output to cause the users forget to commit them. * jl/status-added-submodule-is-never-ignored: commit -m: commit staged submodules regardless of ignore config status/commit: show staged submodules regardless of ignore config
2014-06-25Merge branch 'ym/fix-opportunistic-index-update-race' into maintJunio C Hamano
"git status", even though it is a read-only operation, tries to update the index with refreshed lstat(2) info to optimize future accesses to the working tree opportunistically, but this could race with a "read-write" operation that modify the index while it is running. Detect such a race and avoid overwriting the index. * ym/fix-opportunistic-index-update-race: read-cache.c: verify index file before we opportunistically update it wrapper.c: add xpread() similar to xread()
2014-06-25Merge branch 'jl/remote-rm-prune' into maintJunio C Hamano
"git remote rm" and "git remote prune" can involve removing many refs at once, which is not a very efficient thing to do when very many refs exist in the packed-refs file. * jl/remote-rm-prune: remote prune: optimize "dangling symref" check/warning remote: repack packed-refs once when deleting multiple refs remote rm: delete remote configuration as the last
2014-06-25Merge branch 'fc/rerere-conflict-style' into maintJunio C Hamano
"git rerere forget" did not work well when merge.conflictstyle was set to a non-default value. * fc/rerere-conflict-style: rerere: fix for merge.conflictstyle
2014-06-25Merge branch 'dt/merge-recursive-case-insensitive' into maintJunio C Hamano
On a case insensitive filesystem, merge-recursive incorrectly deleted the file that is to be renamed to a name that is the same except for case differences. * dt/merge-recursive-case-insensitive: mv: allow renaming to fix case on case insensitive filesystems merge-recursive.c: fix case-changing merge bug
2014-06-25Merge branch 'rs/mailinfo-header-cmp' into maintJunio C Hamano
"git mailinfo" used to read beyond the end of header string while parsing an incoming e-mail message to extract the patch. * rs/mailinfo-header-cmp: mailinfo: use strcmp() for string comparison
2014-06-25Merge branch 'jk/index-pack-report-missing' into maintJunio C Hamano
The error reporting from "git index-pack" has been improved to distinguish missing objects from type errors. * jk/index-pack-report-missing: index-pack: distinguish missing objects from type errors
2014-06-25Merge branch 'nd/index-pack-one-fd-per-thread' into maintJunio C Hamano
We used to disable threaded "git index-pack" on platforms without thread-safe pread(); use a different workaround for such platforms to allow threaded "git index-pack". * nd/index-pack-one-fd-per-thread: index-pack: work around thread-unsafe pread()
2014-06-25Merge branch 'sk/spawn-less-case-insensitively-from-grep-O-i' into maintJunio C Hamano
"git grep -O" to show the lines that hit in the pager did not work well with case insensitive search. We now spawn "less" with its "-I" option when it is used as the pager (which is the default). * sk/spawn-less-case-insensitively-from-grep-O-i: git grep -O -i: if the pager is 'less', pass the '-I' option
2014-06-25Merge branch 'nd/daemonize-gc' into maintJunio C Hamano
"git gc --auto" was recently changed to run in the background to give control back early to the end-user sitting in front of the terminal, but it forgot that housekeeping involving reflogs should be done without other processes competing for accesses to the refs. * nd/daemonize-gc: gc --auto: do not lock refs in the background
2014-06-25Merge branch 'jk/diff-follow-must-take-one-pathspec' into maintJunio C Hamano
"git format-patch" did not enforce the rule that the "--follow" option from the log/diff family of commands must be used with exactly one pathspec. * jk/diff-follow-must-take-one-pathspec: move "--follow needs one pathspec" rule to diff_setup_done
2014-06-25Merge branch 'jk/commit-C-pick-empty' into maintJunio C Hamano
"git commit --allow-empty-message -C $commit" did not work when the commit did not have any log message. * jk/commit-C-pick-empty: commit: do not complain of empty messages from -C
2014-06-25Merge branch 'bc/blame-crlf-test' into maintJunio C Hamano
"git blame" assigned the blame to the copy in the working-tree if the repository is set to core.autocrlf=input and the file used CRLF line endings. * bc/blame-crlf-test: blame: correctly handle files regardless of autocrlf
2014-06-25Merge branch 'jx/blame-align-relative-time' into maintJunio C Hamano
"git blame" miscounted number of columns needed to show localized timestamps, resulting in jaggy left-side-edge of the source code lines in its output. * jx/blame-align-relative-time: blame: dynamic blame_date_width for different locales blame: fix broken time_buf paddings in relative timestamp
2014-06-25Merge branch 'jc/apply-ignore-whitespace' into maintJunio C Hamano
"--ignore-space-change" option of "git apply" ignored the spaces at the beginning of line too aggressively, which is inconsistent with the option of the same name "diff" and "git diff" have. * jc/apply-ignore-whitespace: apply --ignore-space-change: lines with and without leading whitespaces do not match
2014-06-23builtin/clone.c: detect a clone starting at a tag correctlyJunio C Hamano
31b808a0 (clone --single: limit the fetch refspec to fetched branch, 2012-09-20) tried to see if the given "branch" to follow is actually a tag at the remote repository by checking with "refs/tags/" but it incorrectly used strstr(3); it is actively wrong to treat a "branch" "refs/heads/refs/tags/foo" and use the logic for the "refs/tags/" ref hierarchy. What the code really wanted to do is to see if it starts with "refs/tags/". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13commit: record buffer length in cacheJeff King
Most callsites which use the commit buffer try to use the cached version attached to the commit, rather than re-reading from disk. Unfortunately, that interface provides only a pointer to the NUL-terminated buffer, with no indication of the original length. For the most part, this doesn't matter. People do not put NULs in their commit messages, and the log code is happy to treat it all as a NUL-terminated string. However, some code paths do care. For example, when checking signatures, we want to be very careful that we verify all the bytes to avoid malicious trickery. This patch just adds an optional "size" out-pointer to get_commit_buffer and friends. The existing callers all pass NULL (there did not seem to be any obvious sites where we could avoid an immediate strlen() call, though perhaps with some further refactoring we could). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13use get_commit_buffer everywhereJeff 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13convert logmsg_reencode to get_commit_bufferJeff 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13use get_cached_commit_buffer where appropriateJeff 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13provide a helper to set the commit bufferJeff King
Right now this is just a one-liner, but abstracting it will make it easier to change later. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-13provide a helper to free commit bufferJeff 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-12Merge branch 'jc/rev-parse-argh-dashed-multi-words' into maintJunio C Hamano
* jc/rev-parse-argh-dashed-multi-words: update-index: fix segfault with missing --cacheinfo argument
2014-06-12logmsg_reencode: return const bufferJeff 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-12do not create "struct commit" with xcallocJeff 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-12commit_tree: take a pointer/len pair rather than a const strbufJeff 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: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-10repack: s/write_bitmap/&s/ in codeJeff King
The config name is "writeBitmaps", so the internal variable missing the plural is unnecessarily confusing to write. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-10repack: respect pack.writebitmapsJeff King
The config option to turn on bitmaps is read all the way down in the plumbing of pack-objects. This makes it hard for other options in the porcelain of repack to make decisions based on the bitmap setting. For example, repack.packKeptObjects tries to kick in by default only when bitmaps are turned on. But it can't do so reliably because it doesn't yet know whether we are using bitmaps. This patch teaches repack to respect pack.writebitmaps. It means we pass a redundant command-line flag to pack-objects, but that's OK; it shouldn't affect the outcome. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-10repack: do not accidentally pack kept objects by defaultJeff King
Commit ee34a2b (repack: add `repack.packKeptObjects` config var, 2014-03-03) added a flag which could duplicate kept objects, but did not mean to turn it on by default. Instead, the option is tied by default to the decision to write bitmaps, like: if (pack_kept_objects < 0) pack_kept_objects = write_bitmap; after which we expect pack_kept_objects to be a boolean 0 or 1. However, that assignment neglects that write_bitmap is _also_ a tri-state with "-1" as the default, and with neither option given, we accidentally turn the option on. This patch is the minimal fix to restore the desired behavior for the default state. Further patches will fix the more complicated cases. Note the update to t7700. It failed to turn on bitmaps, meaning we were actually confirming the wrong behavior! Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-04update-index: fix segfault with missing --cacheinfo argumentJeff King
Running "git update-index --cacheinfo" without any further arguments results in a segfault rather than an error message. Commit ec160ae (update-index: teach --cacheinfo a new syntax "mode,sha1,path", 2014-03-23) added code to examine the format of the argument, but forgot to handle the NULL case. Returning an error from the parser is enough, since we then treat it as an old-style "--cacheinfo <mode> <sha1> <path>", and complain that we have less than 3 arguments to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-02mailinfo: use strcmp() for string comparisonRené Scharfe
The array header is defined as: static const char *header[MAX_HDR_PARSED] = { "From","Subject","Date", }; When looking for the index of a specfic string in that array, simply use strcmp() instead of memcmp(). This avoids running over the end of the string (e.g. with memcmp("Subject", "From", 7)) and gets rid of magic string length constants. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-27builtin/remote.c: rearrange xcalloc argumentsBrian Gesiak
xcalloc() takes two arguments: the number of elements and their size. builtin/remote.c includes several calls to xcalloc() that pass the arguments in reverse order. Rearrange them so they are in the correct order. Signed-off-by: Brian Gesiak <modocache@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-27builtin/ls-remote.c: rearrange xcalloc argumentsBrian Gesiak
xcalloc() takes two arguments: the number of elements and their size. cmd_ls_remote() passes the arguments in reverse order, passing the size of a char*, followed by the number of char* to be allocated. Rearrange them so they are in the correct order. Signed-off-by: Brian Gesiak <modocache@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-27gc --auto: do not lock refs in the backgroundNguyễn Thái Ngọc Duy
9f673f9 (gc: config option for running --auto in background - 2014-02-08) puts "gc --auto" in background to reduce user's wait time. Part of the garbage collecting is pack-refs and pruning reflogs. These require locking some refs and may abort other processes trying to lock the same ref. If gc --auto is fired in the middle of a script, gc's holding locks in the background could fail the script, which could never happen before 9f673f9. Keep running pack-refs and "reflog --prune" in foreground to stop parallel ref updates. The remaining background operations (repack, prune and rerere) should not impact running git processes. Reported-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-27remote prune: optimize "dangling symref" check/warningJens Lindström
When 'git remote prune' was used to delete many refs in a repository with many refs, a lot of time was spent checking for (now) dangling symbolic refs pointing to the deleted ref, since warn_dangling_symref() was once per deleted ref to check all other refs in the repository. Avoid this using the new warn_dangling_symrefs() function which makes one pass over all refs and checks for all the deleted refs in one go, after they have all been deleted. Signed-off-by: Jens Lindström <jl@opera.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-27remote: repack packed-refs once when deleting multiple refsJens Lindström
When 'git remote rm' or 'git remote prune' were used in a repository with many refs, and needed to delete many remote-tracking refs, a lot of time was spent deleting those refs since for each deleted ref, repack_without_refs() was called to rewrite packed-refs without just that deleted ref. To avoid this, call repack_without_refs() first to repack without all the refs that will be deleted, before calling delete_ref() to delete each one completely. The call to repack_without_ref() in delete_ref() then becomes a no-op, since packed-refs already won't contain any of the deleted refs. Signed-off-by: Jens Lindström <jl@opera.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>