summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2016-02-26Merge branch 'ls/config-origin'Libravatar Junio C Hamano1-0/+33
The configuration system has been taught to phrase where it found a bad configuration variable in a better way in its error messages. "git config" learnt a new "--show-origin" option to indicate where the values come from. * ls/config-origin: config: add '--show-origin' option to print the origin of a config value config: add 'origin_type' to config_source struct rename git_config_from_buf to git_config_from_mem t: do not hide Git's exit code in tests using 'nul_to_q'
2016-02-26Merge branch 'jk/tighten-alloc'Libravatar Junio C Hamano21-101/+63
Update various codepaths to avoid manually-counted malloc(). * jk/tighten-alloc: (22 commits) ewah: convert to REALLOC_ARRAY, etc convert ewah/bitmap code to use xmalloc diff_populate_gitlink: use a strbuf transport_anonymize_url: use xstrfmt git-compat-util: drop mempcpy compat code sequencer: simplify memory allocation of get_message test-path-utils: fix normalize_path_copy output buffer size fetch-pack: simplify add_sought_entry fast-import: simplify allocation in start_packfile write_untracked_extension: use FLEX_ALLOC helper prepare_{git,shell}_cmd: use argv_array use st_add and st_mult for allocation size computation convert trivial cases to FLEX_ARRAY macros use xmallocz to avoid size arithmetic convert trivial cases to ALLOC_ARRAY convert manual allocations to argv_array argv-array: add detach function add helpers for allocating flex-array structs harden REALLOC_ARRAY and xcalloc against size_t overflow tree-diff: catch integer overflow in combine_diff_path allocation ...
2016-02-26Merge branch 'tg/git-remote'Libravatar Junio C Hamano2-16/+12
The internal API to interact with "remote.*" configuration variables has been streamlined. * tg/git-remote: remote: use remote_is_configured() for add and rename remote: actually check if remote exits remote: simplify remote_is_configured() remote: use parse_config_key
2016-02-24Merge branch 'jc/am-i-v-fix'Libravatar Junio C Hamano1-1/+1
The "v(iew)" subcommand of the interactive "git am -i" command was broken in 2.6.0 timeframe when the command was rewritten in C. * jc/am-i-v-fix: am -i: fix "v"iew pager: factor out a helper to prepare a child process to run the pager pager: lose a separate argv[]
2016-02-24Merge branch 'nd/worktree-add-B'Libravatar Junio C Hamano1-4/+11
"git worktree add -B <branchname>" did not work. * nd/worktree-add-B: worktree add -B: do the checkout test before update branch worktree: fix "add -B"
2016-02-24Merge branch 'jk/lose-name-path'Libravatar Junio C Hamano2-21/+6
The "name_path" API was an attempt to reduce the need to construct the full path out of a series of path components while walking a tree hierarchy, but over time made less efficient because the path needs to be flattened, e.g. to be compared with another path that is already flat. The API has been removed and its users have been rewritten to simplify the overall code complexity. * jk/lose-name-path: list-objects: pass full pathname to callbacks list-objects: drop name_path entirely list-objects: convert name_path to a strbuf show_object_with_name: simplify by using path_name() http-push: stop using name_path
2016-02-24Merge branch 'ew/force-ipv4'Libravatar Junio C Hamano3-0/+18
"git fetch" and friends that make network connections can now be told to only use ipv4 (or ipv6). * ew/force-ipv4: connect & http: support -4 and -6 switches for remote operations
2016-02-24Merge branch 'nd/git-common-dir-fix'Libravatar Junio C Hamano1-1/+2
"git rev-parse --git-common-dir" used in the worktree feature misbehaved when run from a subdirectory. * nd/git-common-dir-fix: rev-parse: take prefix into account in --git-common-dir
2016-02-24Merge branch 'nd/dwim-wildcards-as-pathspecs'Libravatar Junio C Hamano1-1/+2
"git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a rev, i.e. the object named by the the pathname with wildcard characters in a tree object. * nd/dwim-wildcards-as-pathspecs: get_sha1: don't die() on bogus search strings check_filename: tighten dwim-wildcard ambiguity checkout: reorder check_filename conditional
2016-02-22fetch-pack: simplify add_sought_entryLibravatar Jeff King1-18/+9
We have two variants of this function, one that takes a string and one that takes a ptr/len combo. But we only call the latter with the length of a NUL-terminated string, so our first simplification is to drop it in favor of the string variant. Since we know we have a string, we can also replace the manual memory computation with a call to alloc_ref(). Furthermore, we can rely on get_oid_hex() to complain if it hits the end of the string. That means we can simplify the check for "<sha1> <ref>" versus just "<ref>". Rather than manage the ptr/len pair, we can just bump the start of our string forward. The original code over-allocated based on the original "namelen" (which wasn't _wrong_, but was simply wasteful and confusing). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22use st_add and st_mult for allocation size computationLibravatar Jeff King7-9/+9
If our size computation overflows size_t, we may allocate a much smaller buffer than we expected and overflow it. It's probably impossible to trigger an overflow in most of these sites in practice, but it is easy enough convert their additions and multiplications into overflow-checking variants. This may be fixing real bugs, and it makes auditing the code easier. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22convert trivial cases to FLEX_ARRAY macrosLibravatar Jeff King4-18/+11
Using FLEX_ARRAY macros reduces the amount of manual computation size we have to do. It also ensures we don't overflow size_t, and it makes sure we write the same number of bytes that we allocated. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22use xmallocz to avoid size arithmeticLibravatar Jeff King3-3/+3
We frequently allocate strings as xmalloc(len + 1), where the extra 1 is for the NUL terminator. This can be done more simply with xmallocz, which also checks for integer overflow. There's no case where switching xmalloc(n+1) to xmallocz(n) is wrong; the result is the same length, and malloc made no guarantees about what was in the buffer anyway. But in some cases, we can stop manually placing NUL at the end of the allocated buffer. But that's only safe if it's clear that the contents will always fill the buffer. In each case where this patch does so, I manually examined the control flow, and I tried to err on the side of caution. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22convert trivial cases to ALLOC_ARRAYLibravatar Jeff King9-14/+16
Each of these cases can be converted to use ALLOC_ARRAY or REALLOC_ARRAY, which has two advantages: 1. It automatically checks the array-size multiplication for overflow. 2. It always uses sizeof(*array) for the element-size, so that it can never go out of sync with the declared type of the array. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22convert manual allocations to argv_arrayLibravatar Jeff King3-35/+13
There are many manual argv allocations that predate the argv_array API. Switching to that API brings a few advantages: 1. We no longer have to manually compute the correct final array size (so it's one less thing we can screw up). 2. In many cases we had to make a separate pass to count, then allocate, then fill in the array. Now we can do it in one pass, making the code shorter and easier to follow. 3. argv_array handles memory ownership for us, making it more obvious when things should be free()d and and when not. Most of these cases are pretty straightforward. In some, we switch from "run_command_v" to "run_command" which lets us directly use the argv_array embedded in "struct child_process". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22config: add '--show-origin' option to print the origin of a config valueLibravatar Lars Schneider1-0/+33
If config values are queried using 'git config' (e.g. via --get, --get-all, --get-regexp, or --list flag) then it is sometimes hard to find the configuration file where the values were defined. Teach 'git config' the '--show-origin' option to print the source configuration file for every printed value. Based-on-patch-by: Jeff King <peff@peff.net> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-19reflog_expire_cfg: NUL-terminate pattern fieldLibravatar Jeff King1-5/+3
You can tweak the reflog expiration for a particular subset of refs by configuring gc.foo.reflogexpire. We keep a linked list of reflog_expire_cfg structs, each of which holds the pattern and a "len" field for the length of the pattern. The pattern itself is _not_ NUL-terminated. However, we feed the pattern directly to wildmatch(), which expects a NUL-terminated string, meaning it may keep reading random junk after our struct. We can fix this by allocating an extra byte for the NUL (which is already zero because we use xcalloc). Let's also drop the misleading "len" field, which is no longer necessary. The existing use of "len" can be converted to use strncmp(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17Merge branch 'ah/stripspace-optstring'Libravatar Junio C Hamano1-1/+1
* ah/stripspace-optstring: stripspace: call U+0020 a "space" instead of a "blank"
2016-02-17am -i: fix "v"iewLibravatar Junio C Hamano1-1/+1
The 'v'iew subcommand of the interactive mode of "git am -i" was broken by the rewrite to C we did at around 2.6.0 timeframe at 7ff26832 (builtin-am: implement -i/--interactive, 2015-08-04); we used to spawn the pager via the shell, accepting things like PAGER='less -S' in the environment, but the rewrite forgot and tried to directly spawn a command whose name is the entire string. The previous refactoring of the new helper function makes it easier for us to do the right thing. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-16remote: use remote_is_configured() for add and renameLibravatar Thomas Gummerer1-5/+2
Both remote add and remote rename use a slightly different hand-rolled check if the remote exits. The hand-rolled check may have some subtle cases in which it might fail to detect when a remote already exists. One such case was fixed in fb86e32 ("git remote: allow adding remotes agreeing with url.<...>.insteadOf"). Another case is when a remote is configured as follows: [remote "foo"] vcs = bar If we try to run `git remote add foo bar` with the above remote configuration, git segfaults. This change fixes it. In addition, git remote rename $existing foo with the configuration for foo as above silently succeeds, even though foo already exists, modifying its configuration. With this patch it fails with "remote foo already exists". Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-16remote: actually check if remote exitsLibravatar Thomas Gummerer1-2/+2
When converting the git remote command to a builtin in 211c89 ("Make git-remote a builtin"), a few calls to check if a remote exists were converted from: if (!exists $remote->{$name}) { [...] to: remote = remote_get(argv[1]); if (!remote) [...] The new check is not quite correct, because remote_get() never returns NULL if a name is given. This leaves us with the somewhat cryptic error message "error: Could not remove config section 'remote.test'", if we are trying to remove a remote that does not exist, or a similar error if we try to rename a remote. Use the remote_is_configured() function to check whether the remote actually exists, and die with a more sensible error message ("No such remote: $remotename") instead if it doesn't. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-16remote: simplify remote_is_configured()Libravatar Thomas Gummerer2-9/+8
The remote_is_configured() function allows checking whether a remote exists or not. The function however only works if remote_get() wasn't called before calling it. In addition, it only checks the configuration for remotes, but not remotes or branches files. Make use of the origin member of struct remote instead, which indicates where the remote comes from. It will be set to some value if the remote is configured in any file in the repository, but is initialized to 0 if the remote is only created in make_remote(). Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-15worktree add -B: do the checkout test before update branchLibravatar Nguyễn Thái Ngọc Duy1-1/+10
If --force is not given but -B is, we should not proceed if the given branch is already checked out elsewhere. add_worktree() has this test, but it kicks in too late when "git branch --force" is already executed. As a result, even though we correctly refuse to create a new worktree, we have already updated the branch and mess up the other checkout. Repeat the die_if_checked_out() test again for this specific case before "git branch" runs. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-15worktree: fix "add -B"Libravatar Nguyễn Thái Ngọc Duy1-3/+1
Current code does not update "symref" when -B is used. This string contains the new HEAD. Because it's empty "git worktree add -B" fails at symbolic-ref step. Because branch creation is already done before calling add_worktree(), -B is equivalent to -b from add_worktree() point of view. We do not need the special case for -B. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-12rev-parse: take prefix into account in --git-common-dirLibravatar Nguyễn Thái Ngọc Duy1-1/+2
Most of the time, get_git_common_dir() returns an absolute path so prefix is irrelevant. If it returns a relative path (e.g. from the main worktree) then prefixing is required. Noticed-by: Mike Hommey <mh@glandium.org> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-12list-objects: pass full pathname to callbacksLibravatar Jeff King2-21/+6
When we find a blob at "a/b/c", we currently pass this to our show_object_fn callbacks as two components: "a/b/" and "c". Callbacks which want the full value then call path_name(), which concatenates the two. But this is an inefficient interface; the path is a strbuf, and we could simply append "c" to it temporarily, then roll back the length, without creating a new copy. So we could improve this by teaching the callsites of path_name() this trick (and there are only 3). But we can also notice that no callback actually cares about the broken-down representation, and simply pass each callback the full path "a/b/c" as a string. The callback code becomes even simpler, then, as we do not have to worry about freeing an allocated buffer, nor rolling back our modification to the strbuf. This is theoretically less efficient, as some callbacks would not bother to format the final path component. But in practice this is not measurable. Since we use the same strbuf over and over, our work to grow it is amortized, and we really only pay to memcpy a few bytes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-12list-objects: drop name_path entirelyLibravatar Jeff King2-4/+4
In the previous commit, we left name_path as a thin wrapper around a strbuf. This patch drops it entirely. As a result, every show_object_fn callback needs to be adjusted. However, none of their code needs to be changed at all, because the only use was to pass it to path_name(), which now handles the bare strbuf. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-12connect & http: support -4 and -6 switches for remote operationsLibravatar Eric Wong3-0/+18
Sometimes it is necessary to force IPv4-only or IPv6-only operation on networks where name lookups may return a non-routable address and stall remote operations. The ssh(1) command has an equivalent switches which we may pass when we run them. There may be old ssh(1) implementations out there which do not support these switches; they should report the appropriate error in that case. rsync support is untouched for now since it is deprecated and scheduled to be removed. Signed-off-by: Eric Wong <normalperson@yhbt.net> Reviewed-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-10Merge branch 'jk/options-cleanup'Libravatar Junio C Hamano7-102/+57
Various clean-ups to the command line option parsing. * jk/options-cleanup: apply, ls-files: simplify "-z" parsing checkout-index: disallow "--no-stage" option checkout-index: handle "--no-index" option checkout-index: handle "--no-prefix" option checkout-index: simplify "-z" option parsing give "nbuf" strbuf a more meaningful name
2016-02-10Merge branch 'cc/untracked'Libravatar Junio C Hamano1-23/+39
Update the untracked cache subsystem and change its primary UI from "git update-index" to "git config". * cc/untracked: t7063: add tests for core.untrackedCache test-dump-untracked-cache: don't modify the untracked cache config: add core.untrackedCache dir: simplify untracked cache "ident" field dir: add remove_untracked_cache() dir: add {new,add}_untracked_cache() update-index: move 'uc' var declaration update-index: add untracked cache notifications update-index: add --test-untracked-cache update-index: use enum for untracked cache options dir: free untracked cache when removing it
2016-02-10check_filename: tighten dwim-wildcard ambiguityLibravatar Jeff King1-1/+2
When specifying both revisions and pathnames, we allow "<rev> -- <pathspec>" to be spelled without the "--" as long as it is not ambiguous. The original logic was something like: 1. Resolve each item with get_sha1(). If successful, we know it can be a <rev>. Verify that it _isn't_ a filename, using verify_non_filename(), and complain of ambiguity otherwise. 2. If get_sha1() didn't succeed, make sure that it _is_ a file, using verify_filename(). If not, complain that it is neither a <rev> nor a <pathspec>. Both verify_filename() and verify_non_filename() rely on check_filename(), which definitely said "yes, this is a file" or "no, it is not" using lstat(). Commit 28fcc0b (pathspec: avoid the need of "--" when wildcard is used, 2015-05-02) introduced a convenience feature: check_filename() will consider anything with wildcard meta-characters as a possible filename, without even checking the filesystem. This works well for case 2. For such a wildcard, we would previously have died and said "it is neither". Post-28fcc0b, we assume it's a pathspec and proceed. But it makes some instances of case 1 worse. We may have an extended sha1 expression that contains meta-characters (e.g., "HEAD^{/foo.*bar}"), and we now complain that it's also a filename, due to the wildcard characters (even though that wildcard would not match anything in the filesystem). One solution would be to actually expand the pathname and see if it matches anything on the filesystem. But that's potentially expensive, and we do not have to be so rigorous for this DWIM magic (if you want rigor, use "--"). Instead, we can just use different rules for cases 1 and 2. When we know something is a rev, we will complain only if it meets a much higher standard for "this is also a file"; namely that it actually exists in the filesystem. Case 2 remains the same: we use the looser "it could be a filename" standard introduced by 28fcc0b. We can accomplish this by pulling the wildcard logic out of check_filename() and putting it into verify_filename(). Its partner verify_non_filename() does not need a change, since check_filename() goes back to implementing the "higher standard". Besides these two callers of check_filename(), there is one other: git-checkout does a similar DWIM itself. It hits this code path only after get_sha1() has returned failure, making it case 2, which gets the special wildcard treatment. Note that we drop the tests in t2019 in favor of a more complete set in t6133. t2019 was not the right place for them (it's about refname ambiguity, not dwim parsing ambiguity), and the second test explicitly checked for the opposite result of the case we are fixing here (which didn't really make any sense; as shown by the test_must_fail in the test, it would only serve to annoy people). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-10checkout: reorder check_filename conditionalLibravatar Jeff King1-1/+1
If we have a "--" flag, we should not be doing DWIM magic based on whether arguments can be filenames. Reorder the conditional to avoid the check_filename() call entirely in this case. The outcome is the same, but the short-circuit makes the dependency more clear. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-05Merge branch 'jk/ref-cache-non-repository-optim' into maintLibravatar Junio C Hamano1-25/+1
The underlying machinery used by "ls-files -o" and other commands have been taught not to create empty submodule ref cache for a directory that is not a submodule. This removes a ton of wasted CPU cycles. * jk/ref-cache-non-repository-optim: resolve_gitlink_ref: ignore non-repository paths clean: make is_git_repository a public function
2016-02-05Merge branch 'nd/diff-with-path-params' into maintLibravatar Junio C Hamano2-2/+2
A few options of "git diff" did not work well when the command was run from a subdirectory. * nd/diff-with-path-params: diff: make -O and --output work in subdirectory diff-no-index: do not take a redundant prefix argument
2016-02-05Merge branch 'jk/list-tag-2.7-regression' into maintLibravatar Junio C Hamano1-2/+2
"git tag" started listing a tag "foo" as "tags/foo" when a branch named "foo" exists in the same repository; remove this unnecessary disambiguation, which is a regression introduced in v2.7.0. * jk/list-tag-2.7-regression: tag: do not show ambiguous tag names as "tags/foo" t6300: use test_atom for some un-modern tests
2016-02-05Merge branch 'js/close-packs-before-gc' into maintLibravatar Junio C Hamano4-0/+5
Many codepaths that run "gc --auto" before exiting kept packfiles mapped and left the file descriptors to them open, which was not friendly to systems that cannot remove files that are open. They now close the packs before doing so. * js/close-packs-before-gc: receive-pack: release pack files before garbage-collecting merge: release pack files before garbage-collecting am: release pack files before garbage-collecting fetch: release pack files before garbage-collecting
2016-02-05Merge branch 'js/fopen-harder' into maintLibravatar Junio C Hamano3-3/+3
Some codepaths used fopen(3) when opening a fixed path in $GIT_DIR (e.g. COMMIT_EDITMSG) that is meant to be left after the command is done. This however did not work well if the repository is set to be shared with core.sharedRepository and the umask of the previous user is tighter. They have been made to work better by calling unlink(2) and retrying after fopen(3) fails with EPERM. * js/fopen-harder: Handle more file writes correctly in shared repos commit: allow editing the commit message even in shared repos
2016-02-05Merge branch 'jk/clang-pedantic' into maintLibravatar Junio C Hamano1-1/+1
A few unportable C construct have been spotted by clang compiler and have been fixed. * jk/clang-pedantic: bswap: add NO_UNALIGNED_LOADS define avoid shifting signed integers 31 bits
2016-02-03Merge branch 'jk/ref-cache-non-repository-optim'Libravatar Junio C Hamano1-25/+1
The underlying machinery used by "ls-files -o" and other commands have been taught not to create empty submodule ref cache for a directory that is not a submodule. This removes a ton of wasted CPU cycles. * jk/ref-cache-non-repository-optim: resolve_gitlink_ref: ignore non-repository paths clean: make is_git_repository a public function
2016-02-03Merge branch 'nd/diff-with-path-params'Libravatar Junio C Hamano2-2/+2
A few options of "git diff" did not work well when the command was run from a subdirectory. * nd/diff-with-path-params: diff: make -O and --output work in subdirectory diff-no-index: do not take a redundant prefix argument
2016-02-03Merge branch 'tg/ls-remote-symref'Libravatar Junio C Hamano1-54/+36
"ls-remote" learned an option to show which branch the remote repository advertises as its primary by pointing its HEAD at. * tg/ls-remote-symref: ls-remote: add support for showing symrefs ls-remote: use parse-options api ls-remote: fix synopsis ls-remote: document --refs option ls-remote: document --quiet option
2016-02-03Merge branch 'tb/ls-files-eol'Libravatar Junio C Hamano1-0/+21
"git ls-files" learned a new "--eol" option to help diagnose end-of-line problems. * tb/ls-files-eol: ls-files: add eol diagnostics
2016-02-03Merge branch 'jk/notes-merge-from-anywhere'Libravatar Junio C Hamano1-1/+1
"git notes merge" used to limit the source of the merged notes tree to somewhere under refs/notes/ hierarchy, which was too limiting when inventing a workflow to exchange notes with remote repositories using remote-tracking notes trees (located in e.g. refs/remote-notes/ or somesuch). * jk/notes-merge-from-anywhere: notes: allow merging from arbitrary references
2016-02-03Merge branch 'jc/peace-with-crlf'Libravatar Junio C Hamano7-8/+8
Many commands that read files that are expected to contain text that is generated (or can be edited) by the end user to control their behaviour (e.g. "git grep -f <filename>") have been updated to be more tolerant to lines that are terminated with CRLF (they used to treat such a line to contain payload that ends with CR, which is usually not what the users expect). * jc/peace-with-crlf: test-sha1-array: read command stream with strbuf_getline() grep: read -f file with strbuf_getline() send-pack: read list of refs with strbuf_getline() column: read lines with strbuf_getline() cat-file: read batch stream with strbuf_getline() transport-helper: read helper response with strbuf_getline() clone/sha1_file: read info/alternates with strbuf_getline() remote.c: read $GIT_DIR/remotes/* with strbuf_getline() ident.c: read /etc/mailname with strbuf_getline() rev-parse: read parseopt spec with strbuf_getline() revision: read --stdin with strbuf_getline() hash-object: read --stdin-paths with strbuf_getline()
2016-02-01Merge branch 'jk/list-tag-2.7-regression'Libravatar Junio C Hamano1-2/+2
"git tag" started listing a tag "foo" as "tags/foo" when a branch named "foo" exists in the same repository; remove this unnecessary disambiguation, which is a regression introduced in v2.7.0. * jk/list-tag-2.7-regression: tag: do not show ambiguous tag names as "tags/foo" t6300: use test_atom for some un-modern tests
2016-02-01apply, ls-files: simplify "-z" parsingLibravatar Jeff King2-24/+6
As a short option, we cannot handle negation. Thus a callback handling "unset" is overkill, and we can just use OPT_SET_INT instead to handle setting the option. Anybody who adds "--nul" synonym to this later would need to be careful not to break "--no-nul", which should mean that lines are terminated with LF at the end. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-01checkout-index: disallow "--no-stage" optionLibravatar Jeff King1-3/+3
We do not really expect people to use "--no-stage", but if they do, git currently segfaults. We could instead have it undo the effects of a previous "--stage", but this gets tricky around the "to_tempfile" flag. We cannot simply reset it to 0, because we don't know if it was set by a previous "--stage=all" or an explicit "--temp" option. We could solve this by setting a flag and resolving to_tempfile later, but it's not worth the effort. Nobody actually wants to use "--no-stage"; we are just trying to fix a potential segfault here. While we're in the area, let's improve the user-facing messages for this option. The error string should be translatable, and we should give some hint in the "-h" output about what can go in the argument field. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-01checkout-index: handle "--no-index" optionLibravatar Jeff King1-24/+10
The parsing of "--index" is done in a callback, but it does not handle an "unset" option. We don't necessarily expect anyone to use this, but the current behavior is to treat it exactly like "--index", which would probably be surprising. Instead, let's just turn it into an OPT_BOOL, and handle it after we're done parsing. This makes "--no-index" just work (it cancels a previous "--index"). As a bonus, this makes the logic easier to follow. The old code opened the index during the option parsing, leaving the reader to wonder if there was some timing issue (there isn't; none of the other options care that we've opened it). And then if we found that "--prefix" had been given, we had to rollback the index. Now we can simply avoid opening it in the first place. Note that it might make more sense for checkout-index to complain when "--index --prefix=foo" is given (rather than silently ignoring "--index"), but since it has been that way since 415e96c ([PATCH] Implement git-checkout-cache -u to update stat information in the cache., 2005-05-15), it's safer to leave it as-is. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-01checkout-index: handle "--no-prefix" optionLibravatar Jeff King1-12/+6
We use a custom callback to parse "--prefix", but it does not handle the "unset" case. As a result, passing "--no-prefix" will cause a segfault. We can fix this by switching it to an OPT_STRING, which makes "--no-prefix" counteract a previous "--prefix". Note that this assigns NULL, so we bump our default-case initialization to lower in the main function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-01checkout-index: simplify "-z" option parsingLibravatar Jeff King1-10/+2
Now that we act as a simple bool, there's no need to use a custom callback. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>