summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2017-03-12Merge branch 'jc/diff-populate-filespec-size-only-fix'Libravatar Junio C Hamano1-0/+9
"git diff --quiet" relies on the size field in diff_filespec to be correctly populated, but diff_populate_filespec() helper function made an incorrect short-cut when asked only to populate the size field for paths that need to go through convert_to_git() (e.g. CRLF conversion). * jc/diff-populate-filespec-size-only-fix: diff: do not short-cut CHECK_SIZE_ONLY check in diff_populate_filespec()
2017-03-12Merge branch 'ax/line-log-range-merge-fix'Libravatar Junio C Hamano1-0/+10
The code to parse "git log -L..." command line was buggy when there are many ranges specified with -L; overrun of the allocated buffer has been fixed. * ax/line-log-range-merge-fix: line-log.c: prevent crash during union of too many ranges
2017-03-12Merge branch 'js/realpath-pathdup-fix'Libravatar Junio C Hamano1-0/+8
Git v2.12 was shipped with an embarrassing breakage where various operations that verify paths given from the user stopped dying when seeing an issue, and instead later triggering segfault. * js/realpath-pathdup-fix: real_pathdup(): fix callsites that wanted it to die on error t1501: demonstrate NULL pointer access with invalid GIT_WORK_TREE
2017-03-12Merge branch 'jk/add-i-patch-do-prompt'Libravatar Junio C Hamano1-0/+18
The patch subcommand of "git add -i" was meant to have paths selection prompt just like other subcommand, unlike "git add -p" directly jumps to hunk selection. Recently, this was broken and "add -i" lost the paths selection dialog, but it now has been fixed. * jk/add-i-patch-do-prompt: add--interactive: fix missing file prompt for patch mode with "-i"
2017-03-10Merge branch 'tg/stash-push'Libravatar Junio C Hamano2-3/+161
"git stash save" takes a pathspec so that the local changes can be stashed away only partially. * tg/stash-push: stash: allow pathspecs in the no verb form stash: use stash_push for no verb form stash: teach 'push' (and 'create_stash') to honor pathspec stash: refactor stash_create stash: add test for the create command line arguments stash: introduce push verb
2017-03-10Merge branch 'jt/http-base-url-update-upon-redirect'Libravatar Junio C Hamano2-0/+18
When a redirected http transport gets an error during the redirected request, we ignored the error we got from the server, and ended up giving a not-so-useful error message. * jt/http-base-url-update-upon-redirect: http: attempt updating base URL only if no error
2017-03-10Merge branch 'jh/send-email-one-cc'Libravatar Junio C Hamano1-4/+3
"Cc:" on the trailer part does not have to conform to RFC strictly, unlike in the e-mail header. "git send-email" has been updated to ignore anything after '>' when picking addresses, to allow non-address cruft like " # stable 4.4" after the address. * jh/send-email-one-cc: send-email: only allow one address per body tag
2017-03-10Merge branch 'jk/t6300-cleanup'Libravatar Junio C Hamano1-1/+1
A test that creates a confusing branch whose name is HEAD has been corrected not to do so. * jk/t6300-cleanup: t6300: avoid creating refs/heads/HEAD
2017-03-10Merge branch 'jk/ident-empty'Libravatar Junio C Hamano1-0/+36
user.email that consists of only cruft chars should consistently error out, but didn't. * jk/ident-empty: ident: do not ignore empty config name/email ident: reject all-crud ident name ident: handle NULL email when complaining of empty name ident: mark error messages for translation
2017-03-10Merge branch 'jc/config-case-cmdline-take-2'Libravatar Junio C Hamano1-0/+62
The code to parse "git -c VAR=VAL cmd" and set configuration variable for the duration of cmd had two small bugs, which have been fixed. * jc/config-case-cmdline-take-2: config: use git_config_parse_key() in git_config_parse_parameter() config: move a few helper functions up
2017-03-08real_pathdup(): fix callsites that wanted it to die on errorLibravatar Johannes Schindelin1-1/+1
In 4ac9006f832 (real_path: have callers use real_pathdup and strbuf_realpath, 2016-12-12), we changed the xstrdup(real_path()) pattern to use real_pathdup() directly. The problem with this change is that real_path() calls strbuf_realpath() with die_on_error = 1 while real_pathdup() calls it with die_on_error = 0. Meaning that in cases where real_path() causes Git to die() with an error message, real_pathdup() is silent and returns NULL instead. The callers, however, are ill-prepared for that change, as they expect the return value to be non-NULL (and otherwise the function died with an appropriate error message). Fix this by extending real_pathdup()'s signature to accept the die_on_error flag and simply pass it through to strbuf_realpath(), and then adjust all callers after a careful audit whether they would handle NULLs well. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-08t1501: demonstrate NULL pointer access with invalid GIT_WORK_TREELibravatar Johannes Schindelin1-0/+8
When GIT_WORK_TREE does not specify a valid path, we should error out, instead of crashing. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-03line-log.c: prevent crash during union of too many rangesLibravatar Allan Xavier1-0/+10
The existing implementation of range_set_union does not correctly reallocate memory, leading to a heap overflow when it attempts to union more than 24 separate line ranges. For struct range_set *out to grow correctly it must have out->nr set to the current size of the buffer when it is passed to range_set_grow. However, the existing implementation of range_set_union only updates out->nr at the end of the function, meaning that it is always zero before this. This results in range_set_grow never growing the buffer, as well as some of the union logic itself being incorrect as !out->nr is always true. The reason why 24 is the limit is that the first allocation of size 1 ends up allocating a buffer of size 24 (due to the call to alloc_nr in ALLOC_GROW). This goes some way to explain why this hasn't been caught before. Fix the problem by correctly updating out->nr after reallocating the range_set. As this results in out->nr containing the same value as the variable o, replace o with out->nr as well. Finally, add a new test to help prevent the problem reoccurring in the future. Thanks to Vegard Nossum for writing the test. Signed-off-by: Allan Xavier <allan.x.xavier@oracle.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02diff: do not short-cut CHECK_SIZE_ONLY check in diff_populate_filespec()Libravatar Junio C Hamano1-0/+9
Callers of diff_populate_filespec() can choose to ask only for the size of the blob without grabbing the blob data, and the function, after running lstat() when the filespec points at a working tree file, returns by copying the value in size field of the stat structure into the size field of the filespec when this is the case. However, this short-cut cannot be taken if the contents from the path needs to go through convert_to_git(), whose resulting real blob data may be different from what is in the working tree file. As "git diff --quiet" compares the .size fields of filespec structures to skip content comparison, this bug manifests as a false "there are differences" for a file that needs eol conversion, for example. Reported-by: Mike Crowe <mac@mcrowe.com> Helped-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02add--interactive: fix missing file prompt for patch mode with "-i"Libravatar Jeff King1-0/+18
When invoked as "git add -i", each menu interactive menu option prompts the user to select a list of files. This includes the "patch" option, which gets the list before starting the hunk-selection loop. As "git add -p", it behaves differently, and jumps straight to the hunk selection loop. Since 0539d5e6d (i18n: add--interactive: mark patch prompt for translation, 2016-12-14), the "add -i" case mistakenly jumps to straight to the hunk-selection loop. Prior to that commit the distinction between the two cases was managed by the $patch_mode variable. That commit used $patch_mode for something else, and moved the old meaning to the "$cmd" variable. But it forgot to update the $patch_mode check inside patch_update_cmd() which controls the file-list behavior. The simplest fix would be to change that line to check $cmd. But while we're here, let's use a less obscure name for this flag: $patch_mode_only, a boolean which tells whether we are in full-interactive mode or only in patch-mode. Reported-by: Henrik Grubbström <grubba@grubba.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-28stash: allow pathspecs in the no verb formLibravatar Thomas Gummerer1-0/+15
Now that stash_push is used in the no verb form of stash, allow specifying the command line for this form as well. Always use -- to disambiguate pathspecs from other non-option arguments. Also make git stash -p an alias for git stash push -p. This allows users to use git stash -p <pathspec>. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-28stash: use stash_push for no verb formLibravatar Thomas Gummerer1-3/+1
Now that we have stash_push, which accepts pathspec arguments, use it instead of stash_save in git stash without any additional verbs. Previously we allowed git stash -- -message, which is no longer allowed after this patch. Messages starting with a hyphen was allowed since 3c2eb80f, ("stash: simplify defaulting to "save" and reject unknown options"). However it was never the intent to allow that, but rather it was allowed accidentally. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-28stash: teach 'push' (and 'create_stash') to honor pathspecLibravatar Thomas Gummerer2-0/+118
While working on a repository, it's often helpful to stash the changes of a single or multiple files, and leave others alone. Unfortunately git currently offers no such option. git stash -p can be used to work around this, but it's often impractical when there are a lot of changes over multiple files. Allow 'git stash push' to take pathspec to specify which paths to stash. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-28http: attempt updating base URL only if no errorLibravatar Jonathan Tan2-0/+18
http.c supports HTTP redirects of the form http://foo/info/refs?service=git-upload-pack -> http://anything -> http://bar/info/refs?service=git-upload-pack (that is to say, as long as the Git part of the path and the query string is preserved in the final redirect destination, the intermediate steps can have any URL). However, if one of the intermediate steps results in an HTTP exception, a confusing "unable to update url base from redirection" message is printed instead of a Curl error message with the HTTP exception code. This was introduced by 2 commits. Commit c93c92f ("http: update base URLs when we see redirects", 2013-09-28) introduced a best-effort optimization that required checking if only the "base" part of the URL differed between the initial request and the final redirect destination, but it performed the check before any HTTP status checking was done. If something went wrong, the normal code path was still followed, so this did not cause any confusing error messages until commit 6628eb4 ("http: always update the base URL for redirects", 2016-12-06), which taught http to die if the non-"base" part of the URL differed. Therefore, teach http to check the HTTP status before attempting to check if only the "base" part of the URL differed. This commit teaches http_request_reauth to return early without updating options->base_url upon an error; the only invoker of this function that passes a non-NULL "options" is remote-curl.c (through "http_get_strbuf"), which only uses options->base_url for an informational message in the situations that this commit cares about (that is, when the return value is not HTTP_OK). The included test checks that the redirect scheme at the beginning of this commit message works, and that returning a 502 in the middle of the redirect scheme produces the correct result. Note that this is different from the test in commit 6628eb4 ("http: always update the base URL for redirects", 2016-12-06) in that this commit tests that a Git-shaped URL (http://.../info/refs?service=git-upload-pack) works, whereas commit 6628eb4 tests that a non-Git-shaped URL (http://.../info/refs/foo?service=git-upload-pack) does not work (even though Git is processing that URL) and is an error that is fatal, not silently swallowed. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27Merge branch 'rl/remote-allow-missing-branch-name-merge'Libravatar Junio C Hamano1-0/+19
"git remote rm X", when a branch has remote X configured as the value of its branch.*.remote, tried to remove branch.*.remote and branch.*.merge and failed if either is unset. * rl/remote-allow-missing-branch-name-merge: remote: ignore failure to remove missing branch.<name>.merge
2017-02-27Merge branch 'km/delete-ref-reflog-message'Libravatar Junio C Hamano2-0/+24
"git update-ref -d" and other operations to delete references did not leave any entry in HEAD's reflog when the reference being deleted was the current branch. This is not a problem in practice because you do not want to delete the branch you are currently on, but caused renaming of the current branch to something else not to be logged in a useful way. * km/delete-ref-reflog-message: branch: record creation of renamed branch in HEAD's log rename_ref: replace empty message in HEAD's log update-ref: pass reflog message to delete_ref() delete_ref: accept a reflog message argument
2017-02-27Merge branch 'js/git-path-in-subdir'Libravatar Junio C Hamano3-1/+53
The "--git-path", "--git-common-dir", and "--shared-index-path" options of "git rev-parse" did not produce usable output. They are now updated to show the path to the correct file, relative to where the caller is. * js/git-path-in-subdir: rev-parse: fix several options when running in a subdirectory rev-parse tests: add tests executed from a subdirectory
2017-02-27Merge branch 'jn/remote-helpers-with-git-dir'Libravatar Junio C Hamano2-0/+18
"git ls-remote" and "git archive --remote" are designed to work without being in a directory under Git's control. However, recent updates revealed that we randomly look into a directory called .git/ without actually doing necessary set-up when working in a repository. Stop doing so. * jn/remote-helpers-with-git-dir: remote helpers: avoid blind fall-back to ".git" when setting GIT_DIR remote: avoid reading $GIT_DIR config in non-repo
2017-02-27Merge branch 'jk/grep-no-index-fix'Libravatar Junio C Hamano1-0/+66
The code to parse the command line "git grep <patterns>... <rev> [[--] <pathspec>...]" has been cleaned up, and a handful of bugs have been fixed (e.g. we used to check "--" if it is a rev). * jk/grep-no-index-fix: grep: treat revs the same for --untracked as for --no-index grep: do not diagnose misspelt revs with --no-index grep: avoid resolving revision names in --no-index case grep: fix "--" rev/pathspec disambiguation grep: re-order rev-parsing loop grep: do not unnecessarily query repo for "--" grep: move thread initialization a little lower
2017-02-27Merge branch 'dt/gc-ignore-old-gc-logs'Libravatar Junio C Hamano1-0/+15
A "gc.log" file left by a backgrounded "gc --auto" disables further automatic gc; it has been taught to run at least once a day (by default) by ignoring a stale "gc.log" file that is too old. * dt/gc-ignore-old-gc-logs: gc: ignore old gc.log files
2017-02-27Merge branch 'sf/putty-w-args'Libravatar Junio C Hamano1-0/+41
The command line options for ssh invocation needs to be tweaked for some implementations of SSH (e.g. PuTTY plink wants "-P <port>" while OpenSSH wants "-p <port>" to specify port to connect to), and the variant was guessed when GIT_SSH environment variable is used to specify it. The logic to guess now applies to the command specified by the newer GIT_SSH_COMMAND and also core.sshcommand configuration variable, and comes with an escape hatch for users to deal with misdetected cases. * sf/putty-w-args: connect.c: stop conflating ssh command names and overrides connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config git_connect(): factor out SSH variant handling connect: rename tortoiseplink and putty variables connect: handle putty/plink also in GIT_SSH_COMMAND
2017-02-27Merge branch 'js/rebase-helper'Libravatar Junio C Hamano1-1/+1
"git rebase -i" starts using the recently updated "sequencer" code. * js/rebase-helper: rebase -i: use the rebase--helper builtin rebase--helper: add a builtin helper for interactive rebases
2017-02-27Merge branch 'bw/attr'Libravatar Junio C Hamano1-0/+26
The gitattributes machinery is being taught to work better in a multi-threaded environment. * bw/attr: (27 commits) attr: reformat git_attr_set_direction() function attr: push the bare repo check into read_attr() attr: store attribute stack in attr_check structure attr: tighten const correctness with git_attr and match_attr attr: remove maybe-real, maybe-macro from git_attr attr: eliminate global check_all_attr array attr: use hashmap for attribute dictionary attr: change validity check for attribute names to use positive logic attr: pass struct attr_check to collect_some_attrs attr: retire git_check_attrs() API attr: convert git_check_attrs() callers to use the new API attr: convert git_all_attrs() to use "struct attr_check" attr: (re)introduce git_check_attr() and struct attr_check attr: rename function and struct related to checking attributes attr.c: outline the future plans by heavily commenting Documentation: fix a typo attr.c: add push_stack() helper attr: support quoting pathname patterns in C style attr.c: plug small leak in parse_attr_line() attr.c: tighten constness around "git_attr" structure ...
2017-02-27Merge branch 'sg/completion'Libravatar Junio C Hamano2-75/+503
Clean-up and updates to command line completion (in contrib/). * sg/completion: (22 commits) completion: restore removed line continuating backslash completion: cache the path to the repository completion: extract repository discovery from __gitdir() completion: don't guard git executions with __gitdir() completion: consolidate silencing errors from git commands completion: don't use __gitdir() for git commands completion: respect 'git -C <path>' rev-parse: add '--absolute-git-dir' option completion: fix completion after 'git -C <path>' completion: don't offer commands when 'git --opt' needs an argument completion: list short refs from a remote given as a URL completion: don't list 'HEAD' when trying refs completion outside of a repo completion: list refs from remote when remote's name matches a directory completion: respect 'git --git-dir=<path>' when listing remote refs completion: fix most spots not respecting 'git --git-dir=<path>' completion: ensure that the repository path given on the command line exists completion tests: add tests for the __git_refs() helper function completion tests: check __gitdir()'s output in the error cases completion tests: consolidate getting path of current working directory completion tests: make the $cur variable local to the test helper functions ...
2017-02-27Merge branch 'lt/pathspec-negative'Libravatar Junio C Hamano1-2/+4
The "negative" pathspec feature was somewhat more cumbersome to use than necessary in that its short-hand used "!" which needed to be escaped from shells, and it required "exclude from what?" specified. * lt/pathspec-negative: pathspec: don't error out on all-exclusionary pathspec patterns pathspec magic: add '^' as alias for '!'
2017-02-27Merge branch 'cw/tag-reflog-message'Libravatar Junio C Hamano1-1/+17
"git tag" did not leave useful message when adding a new entry to reflog; this was left unnoticed for a long time because refs/tags/* doesn't keep reflog by default. * cw/tag-reflog-message: tag: generate useful reflog message
2017-02-27Merge branch 'jk/alternate-ref-optim'Libravatar Junio C Hamano1-0/+38
Optimizes resource usage while enumerating refs from alternate object store, to help receiving end of "push" that hosts a repository with many "forks". * jk/alternate-ref-optim: receive-pack: avoid duplicates between our refs and alternates receive-pack: treat namespace .have lines like alternates receive-pack: fix misleading namespace/.have comment receive-pack: use oidset to de-duplicate .have lines add oidset API fetch-pack: cache results of for_each_alternate_ref for_each_alternate_ref: replace transport code with for-each-ref for_each_alternate_ref: pass name/oid instead of ref struct for_each_alternate_ref: use strbuf for path allocation for_each_alternate_ref: stop trimming trailing slashes for_each_alternate_ref: handle failure from real_pathdup()
2017-02-27Merge branch 'kn/ref-filter-branch-list'Libravatar Junio C Hamano4-13/+195
The code to list branches in "git branch" has been consolidated with the more generic ref-filter API. * kn/ref-filter-branch-list: (21 commits) ref-filter: resurrect "strip" as a synonym to "lstrip" branch: implement '--format' option branch: use ref-filter printing APIs branch, tag: use porcelain output ref-filter: allow porcelain to translate messages in the output ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>' ref-filter: Do not abruptly die when using the 'lstrip=<N>' option ref-filter: rename the 'strip' option to 'lstrip' ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal() ref-filter: introduce refname_atom_parser() ref-filter: introduce refname_atom_parser_internal() ref-filter: make "%(symref)" atom work with the ':short' modifier ref-filter: add support for %(upstream:track,nobracket) ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams ref-filter: introduce format_ref_array_item() ref-filter: move get_head_description() from branch.c ref-filter: modify "%(objectname:short)" to take length ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>) ref-filter: include reference to 'used_atom' within 'atom_value' ...
2017-02-27Merge branch 'ps/urlmatch-wildcard'Libravatar Junio C Hamano1-0/+105
The <url> part in "http.<url>.<variable>" configuration variable can now be spelled with '*' that serves as wildcard. E.g. "http.https://*.example.com.proxy" can be used to specify the proxy used for https://a.example.com, https://b.example.com, etc., i.e. any host in the example.com domain. * ps/urlmatch-wildcard: urlmatch: allow globbing for the URL host part urlmatch: include host in urlmatch ranking urlmatch: split host and port fields in `struct url_info` urlmatch: enable normalization of URLs with globs mailmap: add Patrick Steinhardt's work address
2017-02-27Merge branch 'mm/merge-rename-delete-message'Libravatar Junio C Hamano1-0/+23
When "git merge" detects a path that is renamed in one history while the other history deleted (or modified) it, it now reports both paths to help the user understand what is going on in the two histories being merged. * mm/merge-rename-delete-message: merge-recursive: make "CONFLICT (rename/delete)" message show both paths
2017-02-27Merge branch 'mh/ref-remove-empty-directory'Libravatar Junio C Hamano2-1/+28
Deletion of a branch "foo/bar" could remove .git/refs/heads/foo once there no longer is any other branch whose name begins with "foo/", but we didn't do so so far. Now we do. * mh/ref-remove-empty-directory: (23 commits) files_transaction_commit(): clean up empty directories try_remove_empty_parents(): teach to remove parents of reflogs, too try_remove_empty_parents(): don't trash argument contents try_remove_empty_parents(): rename parameter "name" -> "refname" delete_ref_loose(): inline function delete_ref_loose(): derive loose reference path from lock log_ref_write_1(): inline function log_ref_setup(): manage the name of the reflog file internally log_ref_write_1(): don't depend on logfile argument log_ref_setup(): pass the open file descriptor back to the caller log_ref_setup(): improve robustness against races log_ref_setup(): separate code for create vs non-create log_ref_write(): inline function rename_tmp_log(): improve error reporting rename_tmp_log(): use raceproof_create_file() lock_ref_sha1_basic(): use raceproof_create_file() lock_ref_sha1_basic(): inline constant raceproof_create_file(): new function safe_create_leading_directories(): set errno on SCLD_EXISTS safe_create_leading_directories_const(): preserve errno ...
2017-02-27Merge branch 'jk/delta-chain-limit'Libravatar Junio C Hamano1-0/+93
"git repack --depth=<n>" for a long time busted the specified depth when reusing delta from existing packs. This has been corrected. * jk/delta-chain-limit: pack-objects: convert recursion to iteration in break_delta_chain() pack-objects: enforce --depth limit in reused deltas
2017-02-27Merge branch 'jk/describe-omit-some-refs'Libravatar Junio C Hamano2-0/+65
"git describe" and "git name-rev" have been taught to take more than one refname patterns to restrict the set of refs to base their naming output on, and also learned to take negative patterns to name refs not to be used for naming via their "--exclude" option. * jk/describe-omit-some-refs: describe: teach describe negative pattern matches describe: teach --match to accept multiple patterns name-rev: add support to exclude refs by pattern match name-rev: extend --refs to accept multiple patterns doc: add documentation for OPT_STRING_LIST
2017-02-27t6300: avoid creating refs/heads/HEADLibravatar Jeff King1-1/+1
In one test, we use "git checkout --orphan HEAD" to create an unborn branch. Confusingly, the resulting branch is named "refs/heads/HEAD". The original probably meant something like: git checkout --orphan orphaned-branch HEAD Let's just use "orphaned-branch" here to make this less confusing. Putting HEAD in the second argument is already implied. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27send-email: only allow one address per body tagLibravatar Johan Hovold1-4/+3
Adding comments after a tag in the body is a common practise (e.g. in the Linux kernel) and git-send-email has been supporting this for years by removing any trailing cruft after the address. After some recent changes, any trailing comment is now instead appended to the recipient name (with some random white space inserted) resulting in undesirable noise in the headers, for example: CC: "# 3 . 3 . x : 1b9508f : sched : Rate-limit newidle" <stable@vger.kernel.org> Revert to the earlier behaviour of discarding anything after the (first) address in a tag while parsing the body. Note that multiple addresses after are still allowed after a command line switch (and in a CC header field). Also note that --suppress-cc=self was never honoured when using multiple addresses in a tag. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-23config: use git_config_parse_key() in git_config_parse_parameter()Libravatar Junio C Hamano1-0/+62
The parsing of one-shot assignments of configuration variables that come from the command line historically was quite loose and allowed anything to pass. It also downcased everything in the variable name, even a three-level <section>.<subsection>.<variable> name in which the <subsection> part must be treated in a case sensitive manner. Existing git_config_parse_key() helper is used to parse the variable name that comes from the command line, i.e. "git config VAR VAL", and handles these details correctly. Replace the strbuf_tolower() call in git_config_parse_parameter() with a call to it to correct both issues. git_config_parse_key() does a bit more things that are not necessary for the purpose of this codepath (e.g. it allocates a separate buffer to return the canonicalized variable name because it takes a "const char *" input), but we are not in a performance-critical codepath here. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-23ident: do not ignore empty config name/emailLibravatar Jeff King1-0/+11
When we read user.name and user.email from a config file, they go into strbufs. When a caller asks ident_default_name() for the value, we fallback to auto-detecting if the strbuf is empty. That means that explicitly setting an empty string in the config is identical to not setting it at all. This is potentially confusing, as we usually accept a configured value as the final value. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-23ident: reject all-crud ident nameLibravatar Jeff King1-0/+5
An ident name consisting of only "crud" characters (like whitespace or punctuation) is effectively the same as an empty one, because our strbuf_addstr_without_crud() will remove those characters. We reject an empty name when formatting a strict ident, but don't notice an all-crud one because our check happens before the crud-removal step. We could skip past the crud before checking for an empty name, but let's make it a separate code path, for two reasons. One is that we can give a more specific error message. And two is that unlike a blank name, we probably don't want to kick in the fallback-to-username behavior. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-23ident: handle NULL email when complaining of empty nameLibravatar Jeff King1-0/+20
If we see an empty name, we complain about and mention the matching email in the error message (to give it some context). However, the "email" pointer may be NULL here if we were planning to fill it in later from ident_default_email(). This was broken by 59f929596 (fmt_ident: refactor strictness checks, 2016-02-04). Prior to that commit, we would look up the default name and email before doing any other actions. So one solution would be to go back to that. However, we can't just do so blindly. The logic for handling the "!email" condition has grown since then. In particular, looking up the default email can die if getpwuid() fails, but there are other errors that should take precedence. Commit 734c7789a (ident: check for useConfigOnly before auto-detection of name/email, 2016-03-30) reordered the checks so that we prefer the error message for useConfigOnly. Instead, we can observe that while the name-handling depends on "email" being set, the reverse is not true. So we can simply set up the email variable first. This does mean that if both are bogus, we'll complain about the email before the name. But between the two, there is no reason to prefer one over the other. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-21remote: ignore failure to remove missing branch.<name>.mergeLibravatar Ross Lagerwall1-0/+19
It is not all too unusual for a branch to use "branch.<name>.remote" without "branch.<name>.merge". You may be using the 'push.default' configuration set to 'current', for example, and do $ git checkout -b side colleague/side $ git config branch.side.remote colleague However, "git remote rm" to remove the remote used in such a manner fails with "fatal: could not unset 'branch.<name>.merge'" because it assumes that a branch that has .remote defined must also have .merge defined. Detect the "cannot unset because it is not set to begin with" case and ignore it. Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-20branch: record creation of renamed branch in HEAD's logLibravatar Kyle Meyer1-2/+3
Renaming the current branch adds an event to the current branch's log and to HEAD's log. However, the logged entries differ. The entry in the branch's log represents the entire renaming operation (the old and new hash are identical), whereas the entry in HEAD's log represents the deletion only (the new sha1 is null). Extend replace_each_worktree_head_symref(), whose only caller is branch_rename(), to take a reflog message argument. This allows the creation of the new ref to be recorded in HEAD's log. As a result, the renaming event is represented by two entries (a deletion and a creation entry) in HEAD's log. It's a bit unfortunate that the branch's log and HEAD's log now represent the renaming event in different ways. Given that the renaming operation is not atomic, the two-entry form is a more accurate representation of the operation and is more useful for debugging purposes if a failure occurs between the deletion and creation events. It would make sense to move the branch's log to the two-entry form, but this would involve changes to how the rename is carried out and to how the update flags and reflogs are processed for deletions, so it may not be worth the effort. Based-on-patch-by: Jeff King <peff@peff.net> Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-20rename_ref: replace empty message in HEAD's logLibravatar Kyle Meyer1-0/+5
When the current branch is renamed, the deletion of the old ref is recorded in HEAD's log with an empty message. Now that delete_ref() accepts a reflog message, provide a more descriptive message by passing along the log message that is given to rename_ref(). The next step will be to extend HEAD's log to also include the second part of the rename, the creation of the new branch. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-20update-ref: pass reflog message to delete_ref()Libravatar Kyle Meyer1-0/+18
Now that delete_ref() accepts a reflog message, pass the user-provided message to delete_ref() rather than silently dropping it. Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-19stash: add test for the create command line argumentsLibravatar Thomas Gummerer1-0/+18
Currently there is no test showing the expected behaviour of git stash create's command line arguments. Add a test for that to show the current expected behaviour and to make sure future refactorings don't break those expectations. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-19stash: introduce push verbLibravatar Thomas Gummerer1-0/+9
Introduce a new git stash push verb in addition to git stash save. The push verb is used to transition from the current command line arguments to a more conventional way, in which the message is given as an argument to the -m option. This allows us to have pathspecs at the end of the command line arguments like other Git commands do, so that the user can say which subset of paths to stash (and leave others behind). Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>