summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2013-04-17blame: handle broken commit headers gracefullyLibravatar René Scharfe1-3/+8
split_ident_line() can leave us with the pointers date_begin, date_end, tz_begin and tz_end all set to NULL. Check them before use and supply the same fallback values as in the case of a negative return code from split_ident_line(). The "(unknown)" is not actually shown in the output, though, because it will be converted to a number (zero) eventually. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-17cat-file: print tags raw for "cat-file -p"Libravatar Jeff King1-71/+0
When "cat-file -p" prints commits, it shows them in their raw format, since git's format is already human-readable. For tags, however, we print the whole thing raw except for one thing: we convert the timestamp on the tagger line into a human-readable date. This dates all the way back to a0f15fa (Pretty-print tagger dates, 2006-03-01). At that time there was no other way to pretty-print a tag. These days, however, neither of those matters much. The normal way to pretty-print a tag is with "git show", which is much more flexible than "cat-file -p". Commit a0f15fa also built "verify-tag --verbose" (and subsequently "tag -v") around the "cat-file -p" output. However, that behavior was lost in commit 62e09ce (Make git tag a builtin, 2007-07-20), and we went back to printing the raw tag contents. Nobody seems to have noticed the bug since then (and it is arguably a saner behavior anyway, as it shows the actual bytes for which we verified the signature). Let's drop the tagger-date formatting for "cat-file -p". It makes us more consistent with cat-file's commit pretty-printer, and as a bonus, we can drop the hand-rolled tag parsing code in cat-file (which happened to behave inconsistently with the tag pretty-printing code elsewhere). This is a change of output format, so it's possible that some callers could considered this a regression. However, the original behavior was arguably a bug (due to the inconsistency with commits), likely nobody was relying on it (even we do not use it ourselves these days), and anyone relying on the "-p" pretty-printer should be able to expect a change in the output format (i.e., while "cat-file" is plumbing, the output format of "-p" was never guaranteed to be stable). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-12Correct common spelling mistakes in comments and testsLibravatar Stefano Lattarini1-3/+3
Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-12Merge branch 'maint-1.8.1' into maintLibravatar Junio C Hamano1-2/+2
* maint-1.8.1: fast-export: fix argument name in error messages Documentation: distinguish between ref and offset deltas in pack-format
2013-04-12fast-export: fix argument name in error messagesLibravatar Paul Price1-2/+2
The --signed-tags argument is plural, while error messages referred to --signed-tag (singular). Tweak error messages to correspond to the argument. Signed-off-by: Paul Price <price@astro.princeton.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-04Merge branch 'nd/index-pack-threaded-fixes' into maintLibravatar Junio C Hamano1-8/+26
* nd/index-pack-threaded-fixes: index-pack: guard nr_resolved_deltas reads by lock index-pack: protect deepest_delta in multithread code
2013-04-04Merge branch 'jk/index-pack-correct-depth-fix' into maintLibravatar Junio C Hamano1-0/+2
* jk/index-pack-correct-depth-fix: index-pack: always zero-initialize object_entry list
2013-04-03Merge branch 'mg/gpg-interface-using-status' into maintLibravatar Junio C Hamano2-2/+2
Verification of signed tags were not done correctly when not in C or en/US locale. * mg/gpg-interface-using-status: pretty: make %GK output the signing key for signed commits pretty: parse the gpg status lines rather than the output gpg_interface: allow to request status return log-tree: rely upon the check in the gpg_interface gpg-interface: check good signature in a reliable way
2013-04-03Merge branch 'bc/commit-complete-lines-given-via-m-option' into maintLibravatar Junio C Hamano1-1/+3
'git commit -m "$msg"' used to add an extra newline even when $msg already ended with one. * bc/commit-complete-lines-given-via-m-option: Documentation/git-commit.txt: rework the --cleanup section git-commit: only append a newline to -m mesg if necessary t7502: demonstrate breakage with a commit message with trailing newlines t/t7502: compare entire commit message with what was expected
2013-04-03Merge branch 'jc/describe' into maintLibravatar Junio C Hamano1-21/+20
The "--match=<pattern>" option of "git describe", when used with "--all" to allow refs that are not annotated tags to be used as a base of description, did not restrict the output from the command to those that match the given pattern. * jc/describe: describe: --match=<pattern> must limit the refs even when used with --all
2013-04-03Merge branch 'ph/tag-force-no-warn-on-creation' into maintLibravatar Junio C Hamano1-1/+1
"git tag -f <tag>" always said "Updated tag '<tag>'" even when creating a new tag (i.e. not overwriting nor updating). * ph/tag-force-no-warn-on-creation: tag: --force does not have to warn when creating tags
2013-04-03Sync with 1.8.1 maintenance trackLibravatar Junio C Hamano2-6/+2
* maint-1.8.1: Start preparing for 1.8.1.6 git-tag(1): we tag HEAD by default Fix revision walk for commits with the same dates t2003: work around path mangling issue on Windows pack-refs: add fully-peeled trait pack-refs: write peeled entry for non-tags use parse_object_or_die instead of die("bad object") avoid segfaults on parse_object failure entry: fix filter lookup t2003: modernize style name-hash.c: fix endless loop with core.ignorecase=true
2013-04-03Merge branch 'jk/fully-peeled-packed-ref' into maint-1.8.1Libravatar Junio C Hamano2-6/+2
* jk/fully-peeled-packed-ref: pack-refs: add fully-peeled trait pack-refs: write peeled entry for non-tags use parse_object_or_die instead of die("bad object") avoid segfaults on parse_object failure
2013-04-03Merge branch 'ap/maint-update-index-h-is-for-help' into maint-1.8.1Libravatar Junio C Hamano1-1/+1
* ap/maint-update-index-h-is-for-help: update-index: allow "-h" to also display options
2013-04-03Merge branch 'nd/index-pack-l10n-buf-overflow' into maint-1.8.1Libravatar Junio C Hamano1-4/+5
* nd/index-pack-l10n-buf-overflow: index-pack: fix buffer overflow caused by translations
2013-03-29cat-file: Fix an gcc -Wuninitialized warningLibravatar Ramsay Jones1-1/+1
After commit cbfd5e1c ("drop some obsolete "x = x" compiler warning hacks", 21-03-2013) removed a gcc specific hack, older versions of gcc now issue an "'contents' might be used uninitialized" warning. In order to suppress the warning, we simply initialize the variable to NULL in it's declaration. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-27Merge branch 'maint-1.8.1' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.8.1: merge-tree: fix typo in merge-tree.c::unresolved git-commit doc: describe use of multiple `-m` options git-pull doc: fix grammo ("conflicts" is plural)
2013-03-27merge-tree: fix typo in merge-tree.c::unresolvedLibravatar John Keeping1-1/+1
When calculating whether there is a d/f conflict, the calculation of whether both sides are directories generates an incorrect references mask because it does not use the loop index to set the correct bit. Fix this typo. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-26Merge branch 'jk/mailsplit-maildir-muttsort' into maintLibravatar Junio C Hamano1-0/+23
Sort filenames read from the maildir/ in a way that is more likely to sort messages in the order the writing MUA meant to, by sorting numeric segment in numeric order and non-numeric segment in alphabetical order. * jk/mailsplit-maildir-muttsort: mailsplit: sort maildir filenames more cleverly
2013-03-26Merge branch 'nd/branch-error-cases' into maintLibravatar Junio C Hamano1-0/+27
"git branch" had more cases where it did not bother to check nonsense command line parameters. * nd/branch-error-cases: branch: segfault fixes and validation
2013-03-26Merge branch 'ap/maint-update-index-h-is-for-help' into maintLibravatar Junio C Hamano1-1/+1
"git update-index -h" did not do the usual "-h(elp)" thing. * ap/maint-update-index-h-is-for-help: update-index: allow "-h" to also display options
2013-03-26Merge branch 'nd/index-pack-l10n-buf-overflow' into maintLibravatar Junio C Hamano1-4/+5
* nd/index-pack-l10n-buf-overflow: index-pack: fix buffer overflow caused by translations
2013-03-26Merge branch 'gp/avoid-explicit-mention-of-dot-git-refs' into maintLibravatar Junio C Hamano1-2/+2
* gp/avoid-explicit-mention-of-dot-git-refs: Fix ".git/refs" stragglers
2013-03-26Merge branch 'jc/maint-reflog-expire-clean-mark-typofix' into maintLibravatar Junio C Hamano1-1/+1
In "git reflog expire", REACHABLE bit was not cleared from the correct objects. * jc/maint-reflog-expire-clean-mark-typofix: reflog: fix typo in "reflog expire" clean-up codepath
2013-03-21drop some obsolete "x = x" compiler warning hacksLibravatar Jeff King1-1/+1
In cases where the setting and access of a variable are protected by the same conditional flag, older versions of gcc would generate a "might be used unitialized" warning. We silence the warning by initializing the variable to itself, a hack that gcc recognizes. Modern versions of gcc are smart enough to get this right, going back to at least version 4.3.5. gcc 4.1 does get it wrong in both cases, but is sufficiently old that we probably don't need to care about it anymore. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20index-pack: always zero-initialize object_entry listLibravatar Jeff King1-0/+2
Commit 38a4556 (index-pack: start learning to emulate "verify-pack -v", 2011-06-03) added a "delta_depth" counter to each "struct object_entry". Initially, all object entries have their depth set to 0; in resolve_delta, we then set the depth of each delta to "base + 1". Base entries never have their depth touched, and remain at 0. To ensure that all depths start at 0, that commit changed calls to xmalloc the object_entry list into calls to xcalloc. However, it forgot that we grow the list with xrealloc later. These extra entries are used when we add an object from elsewhere to complete a thin pack. If we add a non-delta object, its depth value will just be uninitialized heap data. This patch fixes it by zero-initializing entries we add to the objects list via the xrealloc. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-19index-pack: guard nr_resolved_deltas reads by lockLibravatar Thomas Rast1-1/+3
The threaded parts of index-pack increment the number of resolved deltas in nr_resolved_deltas guarded by counter_mutex. However, the per-thread outer loop accessed nr_resolved_deltas without any locks. This is not wrong as such, since it doesn't matter all that much whether we get an outdated value. However, unless someone proves that this one lock makes all the performance difference, it would be much cleaner to guard _all_ accesses to the variable with the lock. The only such use is display_progress() in the threaded section (all others are in the conclude_pack() callchain outside the threaded part). To make it obvious that it cannot deadlock, move it out of work_mutex. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Reviewed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-19index-pack: protect deepest_delta in multithread codeLibravatar Nguyễn Thái Ngọc Duy1-7/+23
deepest_delta is a global variable but is updated without protection in resolve_delta(), a multithreaded function. Add a new mutex for it, but only protect and update when it's actually used (i.e. show_stat is non-zero). Another variable that will not be updated is delta_depth in "struct object_entry" as it's only useful when show_stat is 1. Putting it in "if (show_stat)" makes it clearer. The local variable "stat" is renamed to "show_stat" after moving to global scope because the name "stat" conflicts with stat(2) syscall. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-17use parse_object_or_die instead of die("bad object")Libravatar Jeff King2-6/+2
Some call-sites do: o = parse_object(sha1); if (!o) die("bad object %s", some_name); We can now handle that as a one-liner, and get more consistent output. In the third case of this patch, it looks like we are losing information, as the existing message also outputs the sha1 hex; however, parse_object will already have written a more specific complaint about the sha1, so there is no point in repeating it here. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-16index-pack: fix buffer overflow caused by translationsLibravatar Nguyễn Thái Ngọc Duy1-4/+5
The translation of "completed with %d local objects" is put in a 48-byte buffer, which may be enough for English but not true for any translations. Convert it to use strbuf (i.e. no hard limit on translation length). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-13tag: --force does not have to warn when creating tagsLibravatar Phil Hord1-1/+1
"git tag --force" mentions what old tag object is being replaced when it is used to update an existing tag, but it shows the same message when creating a new one. Stop doing that, as it does not add any information. Add a test for this and also to ensure --force can replace tags at all. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-11add: update pathless 'add [-u|-A]' warning to reflect change of planLibravatar Matthieu Moy1-3/+3
We originally thought the transition would need a period where "git add [-u|-A]" without pathspec would be forbidden, but the warning is big enough to scare people and teach them not to use it (or, if so, to understand the consequences). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-05reflog: fix typo in "reflog expire" clean-up codepathLibravatar Junio C Hamano1-1/+1
In "reflog expire" we were not clearing the REACHABLE bit from objects reachable from the tip of refs we marked earlier. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-02mailsplit: sort maildir filenames more cleverlyLibravatar Jeff King1-0/+23
A maildir does not technically record the order in which items were placed into it. That means that when applying a patch series from a maildir, we may get the patches in the wrong order. We try to work around this by sorting the filenames. Unfortunately, this may or may not work depending on the naming scheme used by the writer of the maildir. For instance, mutt will write: ${epoch_seconds}.${pid}_${seq}.${host} where we have: - epoch_seconds: timestamp at which entry was written - pid: PID of writing process - seq: a sequence number to ensure uniqueness of filenames - host: hostname None of the numbers are zero-padded. Therefore, when we sort the names as byte strings, entries that cross a digit boundary (e.g., 10) will sort out of order. In the case of timestamps, it almost never matters (because we do not cross a digit boundary in the epoch time very often these days). But for the sequence number, a 10-patch series would be ordered as 1, 10, 2, 3, etc. To fix this, we can use a custom sort comparison function which traverses each string, comparing chunks of digits numerically, and otherwise doing a byte-for-byte comparison. That would sort: 123.456_1.bar 123.456_2.bar ... 123.456_10.bar according to the sequence number. Since maildir does not define a filename format, this is really just a heuristic. But it happens to work for mutt, and there is a reasonable chance that it will work for other writers, too (at least as well as a straight sort). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-28describe: --match=<pattern> must limit the refs even when used with --allLibravatar Junio C Hamano1-21/+20
The logic to limit the refs used for describing with a matching pattern with --match=<pattern> parameter was implemented incorrectly when --all is in effect. It just demoted a ref that did not match the pattern to lower priority---if there aren't other refs with higher priority that describe the given commit, such an unmatching ref was still used. When --match is used, reject refs that do not match the given criteria, so that with or without --all, the output will only use refs that match the pattern. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-25Merge branch 'as/check-ignore'Libravatar Junio C Hamano1-1/+1
"git check-ignore ." segfaulted, as a function it calls deep in its callchain took a string in the <ptr, length> form but did not stop when given an empty string. * as/check-ignore: name-hash: allow hashing an empty string t0008: document test_expect_success_multi
2013-02-25Merge branch 'jk/apply-similaritly-parsing' into maintLibravatar Junio C Hamano1-4/+6
* jk/apply-similaritly-parsing: builtin/apply: tighten (dis)similarity index parsing
2013-02-25Merge branch 'zk/clean-report-failure' into maintLibravatar Junio C Hamano1-29/+125
* zk/clean-report-failure: git-clean: Display more accurate delete messages
2013-02-25Merge branch 'nd/clone-no-separate-git-dir-with-bare' into maintLibravatar Junio C Hamano1-0/+2
* nd/clone-no-separate-git-dir-with-bare: clone: forbid --bare --separate-git-dir <dir>
2013-02-24Fix ".git/refs" stragglersLibravatar Greg Price1-2/+2
A couple of references still survive to .git/refs as a tree of all refs. Fix one in docs, one in a -h message, one in a -h message quoted in docs. Signed-off-by: Greg Price <price@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-23update-index: allow "-h" to also display optionsLibravatar Antoine Pelisse1-1/+1
Even though "git update-index" was updated to use parse-options infrastracture some time ago to make it possible to show list of options with usage_with_options(), "git update-index -h" only shows the usage. Detect this case and call usage_with_options() to show the list of options as well. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-23branch: segfault fixes and validationLibravatar Nguyễn Thái Ngọc Duy1-0/+27
branch_get() can return NULL (so far on detached HEAD only) but some code paths in builtin/branch.c cannot deal with that and cause segfaults. While at there, make sure to bail out when the user gives 2 or more branches with --set-upstream-to or --unset-upstream, where only the first branch is processed and the rest silently dropped. Reported-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19name-hash: allow hashing an empty stringLibravatar Junio C Hamano1-1/+1
Usually we do not pass an empty string to the function hash_name() because we almost always ask for hash values for a path that is a candidate to be added to the index. However, check-ignore (and most likely check-attr, but I didn't check) apparently has a callchain to ask the hash value for an empty path when it was given a "." from the top-level directory to ask "Is the path . excluded by default?" Make sure that hash_name() does not overrun the end of the given pathname even when it is empty. Remove a sweep-the-issue-under-the-rug conditional in check-ignore that avoided to pass an empty string to the callchain while at it. It is a valid question to ask for check-ignore if the top-level is set to be ignored by default, even though the answer is most likely no, if only because there is currently no way to specify such an entry in the .gitignore file. But it is an unusual thing to ask and it is not worth optimizing for it by special casing at the top level of the call chain. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19git-commit: only append a newline to -m mesg if necessaryLibravatar Brandon Casey1-1/+3
Currently, git will append two newlines to every message supplied via the -m switch. The purpose of this is to allow -m to be supplied multiple times and have each supplied string become a paragraph in the resulting commit message. Normally, this does not cause a problem since any trailing newlines will be removed by the cleanup operation. If cleanup=verbatim for example, then the trailing newlines will not be removed and will survive into the resulting commit message. Instead, let's ensure that the string supplied to -m is newline terminated, but only append a second newline when appending additional messages. Fixes the test in t7502. Signed-off-by: Brandon Casey <drafnel@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-17Merge branch 'jc/hidden-refs'Libravatar Junio C Hamano1-0/+24
Allow the server side to redact the refs/ namespace it shows to the client. Will merge to 'master'. * jc/hidden-refs: upload/receive-pack: allow hiding ref hierarchies upload-pack: simplify request validation upload-pack: share more code
2013-02-14Merge branch 'jc/extended-fake-ancestor-for-gitlink'Libravatar Junio C Hamano1-2/+38
Instead of requiring the full 40-hex object names on the index line, we can read submodule commit object names from the textual diff when synthesizing a fake ancestore tree for "git am -3". * jc/extended-fake-ancestor-for-gitlink: apply: verify submodule commit object name better
2013-02-14gpg_interface: allow to request status returnLibravatar Michael J Gruber2-2/+2
Currently, verify_signed_buffer() returns the user facing output only. Allow callers to request the status output also. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-12Merge branch 'maint'Libravatar Junio C Hamano2-3/+3
* maint: Replace filepattern with pathspec for consistency
2013-02-12Replace filepattern with pathspec for consistencyLibravatar Matthieu Moy2-3/+3
pathspec is the most widely used term, and is the one defined in gitglossary.txt. <filepattern> was used only in the synopsys for git-add and git-commit, and in git-add.txt. Get rid of it. This patch is obtained with by running: perl -pi -e 's/filepattern/pathspec/' `git grep -l filepattern` Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-08Merge branch 'jk/apply-similaritly-parsing'Libravatar Junio C Hamano1-4/+6
Make sure the similarity value shown in the "apply --summary" output is sensible, even when the input had a bogus value. * jk/apply-similaritly-parsing: builtin/apply: tighten (dis)similarity index parsing