summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2013-05-03Merge branch 'tr/remote-tighten-commandline-parsing' into maintLibravatar Junio C Hamano1-1/+1
* tr/remote-tighten-commandline-parsing: remote: 'show' and 'prune' can take more than one remote remote: check for superfluous arguments in 'git remote add' remote: add a test for extra arguments, according to docs
2013-04-26Merge branch 'jk/receive-pack-deadlocks-with-early-failure' into maintLibravatar Junio C Hamano1-1/+4
* jk/receive-pack-deadlocks-with-early-failure: receive-pack: close sideband fd on early pack errors
2013-04-26Merge branch 'jk/chopped-ident' into maintLibravatar Junio C Hamano2-74/+8
* jk/chopped-ident: blame: handle broken commit headers gracefully pretty: handle broken commit headers gracefully cat-file: print tags raw for "cat-file -p"
2013-04-26Merge branch 'rt/commentchar-fmt-merge-msg' into maintLibravatar Junio C Hamano1-7/+11
* rt/commentchar-fmt-merge-msg: t6200: avoid path mangling issue on Windows fmt-merge-msg: use core.commentchar in tag signatures completely fmt-merge-msg: respect core.commentchar in people credits
2013-04-24Merge branch 'jc/merge-tag-object' into maintLibravatar Junio C Hamano1-0/+13
"git merge $(git rev-parse v1.8.2)" behaved quite differently from "git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did not pay much attention to the annotated tag payload. Make the code notice the type of the tag object, in addition to the dwim_ref() based classification the current code uses (i.e. the name appears in refs/tags/) to decide when to special case merging of tags. * jc/merge-tag-object: t6200: test message for merging of an annotated tag t6200: use test_config/test_unconfig merge: a random object may not necssarily be a commit
2013-04-24remote: check for superfluous arguments in 'git remote add'Libravatar Thomas Rast1-1/+1
The 'git remote add' subcommand did not check for superfluous command line arguments. Make it so. Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-24cherry-pick/revert: make usage say '<commit-ish>...'Libravatar Kevin Bracey1-2/+2
The usage string for cherry-pick and revert has never been updated to reflect their ability to handle multiple commits. Other documentation is already correct. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-22Merge branch 'jk/show-branch-strbuf' into maintLibravatar Junio C Hamano1-9/+8
* jk/show-branch-strbuf: show-branch: use strbuf instead of static buffer
2013-04-22Merge branch 'jc/apply-ws-fix-tab-in-indent' into maintLibravatar Junio C Hamano1-6/+10
* jc/apply-ws-fix-tab-in-indent: test: resurrect q_to_tab apply --whitespace=fix: avoid running over the postimage buffer
2013-04-19receive-pack: close sideband fd on early pack errorsLibravatar Jeff King1-1/+4
Since commit a22e6f8 (receive-pack: send pack-processing stderr over sideband, 2012-09-21), receive-pack will start an async sideband thread to copy the stderr from our index-pack or unpack-objects child to the client. We hand the thread's input descriptor to unpack(), which puts it in the "err" member of the "struct child_process". After unpack() returns, we use finish_async() to reap the sideband thread. The thread is only ready to die when it gets EOF on its pipe, which is connected to the err descriptor. So we expect all of the write ends of that pipe to be closed as part of unpack(). Normally, this works fine. After start_command forks, it closes the parent copy of the descriptor. Then once the child exits (whether it was successful or not), that closes the only remaining writer. However, there is one code-path in unpack() that does not handle this. Before we decide which of unpack-objects or index-pack to use, we read the pack header ourselves to see how many objects it contains. If there is an error here, we exit without running either sub-command, the pipe descriptor remains open, and we are in a deadlock, waiting for the sideband thread to die (which is in turn waiting for us to close the pipe). We can fix this by making sure that unpack() always closes the pipe before returning. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-07fmt-merge-msg: use core.commentchar in tag signatures completelyLibravatar Ralf Thielow1-4/+8
Commit eff80a9 (Allow custom "comment char") introduced a custom comment character for commit messages but didn't use it completely in the tag signature part. This commit fixes that. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-07fmt-merge-msg: respect core.commentchar in people creditsLibravatar Ralf Thielow1-3/+3
Commit eff80a9 (Allow custom "comment char") introduced a custom comment character for commit messages but forgot to use it in people credits which can be a part of a commit message. With this commit, the custom comment character is also used in people credits. Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-06show-branch: use strbuf instead of static bufferLibravatar Jeff King1-9/+8
When we generate relative names (e.g., "master~20^2"), we format the name into a static buffer, then xstrdup the result to attach it to the commit. Since the first thing we add into the static buffer is the already-computed name of the child commit, the names may get longer and longer as the traversal gets deeper, and we may eventually overflow the fixed-size buffer. Fix this by converting the fixed-size buffer into a dynamic strbuf. The performance implications should be minimal, as we end up allocating a heap copy of the name anyway (and now we can just detach the heap copy from the strbuf). Reported-by: Eric Roman <eroman@chromium.org> Signed-off-by: Jeff King <peff@peff.net> 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-22apply --whitespace=fix: avoid running over the postimage bufferLibravatar Junio C Hamano1-6/+10
Originally update-pre-post-images could assume that any whitespace fixing will make the result only shorter by unexpanding runs of leading SPs into HTs and removing trailing whitespaces at the end of lines. Updating the post-image we read from the patch to match the actual result can be performed in-place under this assumption. These days, however, we have tab-in-indent (aka Python) rule whose result can be longer than the original, and we do need to allocate a larger buffer than the input and replace the result. Fortunately the support for lengthening rewrite was already added when we began supporting "match while ignoring whitespace differences" mode in 86c91f91794c (git apply: option to ignore whitespace differences, 2009-08-04). We only need to correctly count the number of bytes necessary to hold the updated result and tell the function to allocate a new buffer. Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-19merge: a random object may not necssarily be a commitLibravatar Junio C Hamano1-0/+13
The user could have said "git merge $(git rev-parse v1.0.0)"; we shouldn't mark it as "Merge commit '15999998fb...'" as the merge name, even though such an invocation might be crazy. We could even read the "tag " header from the tag object and replace the object name the user gave us, but let's not lose the information by doing so, at least not yet. 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>