summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2016-07-06Merge branch 'jk/string-list-static-init'Libravatar Junio C Hamano7-17/+20
Instead of taking advantage of a struct string_list that is allocated with all NULs happens to be STRING_LIST_INIT_NODUP kind, initialize them explicitly as such, to document their behaviour better. * jk/string-list-static-init: use string_list initializer consistently blame,shortlog: don't make local option variables static interpret-trailers: don't duplicate option strings parse_opt_string_list: stop allocating new strings
2016-07-06Merge branch 'pb/commit-editmsg-path'Libravatar Junio C Hamano1-7/+8
Code clean-up. * pb/commit-editmsg-path: builtin/commit.c: memoize git-path for COMMIT_EDITMSG
2016-06-27Merge branch 'lf/receive-pack-auto-gc-to-client'Libravatar Junio C Hamano1-2/+13
Allow messages that are generated by auto gc during "git push" on the receiving end to be explicitly passed back to the sending end over sideband, so that they are shown with "remote: " prefix to avoid confusing the users. * lf/receive-pack-auto-gc-to-client: receive-pack: send auto-gc output over sideband 2
2016-06-27Merge branch 'jc/deref-tag'Libravatar Junio C Hamano1-4/+2
Code clean-up. * jc/deref-tag: blame, line-log: do not loop around deref_tag()
2016-06-27Merge branch 'et/add-chmod-x'Libravatar Junio C Hamano3-11/+26
"git update-index --add --chmod=+x file" may be usable as an escape hatch, but not a friendly thing to force for people who do need to use it regularly. "git add --chmod=+x file" can be used instead. * et/add-chmod-x: add: add --chmod=+x / --chmod=-x options
2016-06-27Merge branch 'cc/apply-introduce-state'Libravatar Junio C Hamano1-609/+820
The "git apply" standalone program is being libified; this is the first step to move many state variables into a structure that can be explicitly (re)initialized to make the machinery callable more than once. The next step that moves some remaining state variables into the structure and turns die()s into an error return that propagates up to the caller is not queued yet but in flight. It would be good to review the above first and give the remainder of the series a solid base to build on. * cc/apply-introduce-state: (50 commits) builtin/apply: remove misleading comment on lock_file field builtin/apply: move 'newfd' global into 'struct apply_state' builtin/apply: add 'lock_file' pointer into 'struct apply_state' builtin/apply: move applying patches into apply_all_patches() builtin/apply: move 'state' check into check_apply_state() builtin/apply: move 'symlink_changes' global into 'struct apply_state' builtin/apply: move 'fn_table' global into 'struct apply_state' builtin/apply: move 'state_linenr' global into 'struct apply_state' builtin/apply: move 'max_change' and 'max_len' into 'struct apply_state' builtin/apply: move 'ws_ignore_action' into 'struct apply_state' builtin/apply: move 'ws_error_action' into 'struct apply_state' builtin/apply: move 'applied_after_fixing_ws' into 'struct apply_state' builtin/apply: move 'squelch_whitespace_errors' into 'struct apply_state' builtin/apply: remove whitespace_option arg from set_default_whitespace_mode() builtin/apply: move 'whitespace_option' into 'struct apply_state' builtin/apply: move 'whitespace_error' global into 'struct apply_state' builtin/apply: move 'root' global into 'struct apply_state' builtin/apply: move 'p_value_known' global into 'struct apply_state' builtin/apply: move 'p_value' global into 'struct apply_state' builtin/apply: move 'has_include' global into 'struct apply_state' ...
2016-06-20Merge branch 'jk/rev-list-count-with-bitmap'Libravatar Junio C Hamano1-1/+5
"git rev-list --count" whose walk-length is limited with "-n" option did not work well with the counting optimized to look at the bitmap index. * jk/rev-list-count-with-bitmap: rev-list: disable bitmaps when "-n" is used with listing objects rev-list: "adjust" results of "--count --use-bitmap-index -n"
2016-06-20Merge branch 'jc/clear-pathspec'Libravatar Junio C Hamano3-5/+5
We usually call a function that clears the contents a data structure X without freeing the structure itself clear_X(), and call a function that does clear_X() and also frees it free_X(). free_pathspec() function has been renamed to clear_pathspec() to avoid confusion. * jc/clear-pathspec: pathspec: rename free_pathspec() to clear_pathspec()
2016-06-20Merge branch 'jg/dash-is-last-branch-in-worktree-add'Libravatar Junio C Hamano1-0/+3
"git worktree add" learned that '-' can be used as a short-hand for "@{-1}", the previous branch. * jg/dash-is-last-branch-in-worktree-add: worktree: allow "-" short-hand for @{-1} in add command
2016-06-20Merge branch 'sb/submodule-recommend-shallowness'Libravatar Junio C Hamano1-1/+6
An upstream project can make a recommendation to shallowly clone some submodules in the .gitmodules file it ships. * sb/submodule-recommend-shallowness: submodule update: learn `--[no-]recommend-shallow` option submodule-config: keep shallow recommendation around
2016-06-20Merge branch 'ah/no-verify-signature-with-pull-rebase'Libravatar Junio C Hamano1-0/+3
"git pull --rebase --verify-signature" learned to warn the user that "--verify-signature" is a no-op when rebasing. * ah/no-verify-signature-with-pull-rebase: pull: warn on --verify-signatures with --rebase
2016-06-14blame, line-log: do not loop around deref_tag()Libravatar Junio C Hamano1-4/+2
These callers appear to expect that deref_tag() is to peel one layer of a tag, but the function does not work that way; it has its own loop to unwrap tags until an object that is not a tag appears. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-13use string_list initializer consistentlyLibravatar Jeff King5-10/+10
There are two types of string_lists: those that own the string memory, and those that don't. You can tell the difference by the strdup_strings flag, and one should use either STRING_LIST_INIT_DUP, or STRING_LIST_INIT_NODUP as an initializer. Historically, the normal all-zeros initialization has corresponded to the NODUP case. Many sites use no initializer at all, and that works as a shorthand for that case. But for a reader of the code, it can be hard to remember which is which. Let's be more explicit and actually have each site declare which type it means to use. This is a fairly mechanical conversion; I assumed each site was correct as-is, and just switched them all to NODUP. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-13Merge branch 'jk/parseopt-string-list' into jk/string-list-static-initLibravatar Junio C Hamano3-10/+10
* jk/parseopt-string-list: blame,shortlog: don't make local option variables static interpret-trailers: don't duplicate option strings parse_opt_string_list: stop allocating new strings
2016-06-13blame,shortlog: don't make local option variables staticLibravatar Jeff King2-9/+9
There's no need for these option variables to be static, except that they are referenced by the options array itself, which is static. But having all of this static is simply unnecessary and confusing (and inconsistent with most other commands, which either use a static global option list or a true function-local one). Note that in some cases we may need to actually initialize the variables (since we cannot rely on BSS to do so). This is a net improvement to readability, though, as we can use the more verbose initializers for our string_lists. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-13interpret-trailers: don't duplicate option stringsLibravatar Jeff King1-1/+1
There's no need to do so; the argv strings will last until the end of the program. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-09builtin/commit.c: memoize git-path for COMMIT_EDITMSGLibravatar Pranit Bauva1-7/+8
This is a follow up commit for f932729c (memoize common git-path "constant" files, 10-Aug-2015). The many function calls to git_path() are replaced by git_path_commit_editmsg() and which thus eliminates the need to repeatedly compute the location of "COMMIT_EDITMSG". Mentored-by: Lars Schneider <larsxschneider@gmail.com> Mentored-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-07add: add --chmod=+x / --chmod=-x optionsLibravatar Edward Thomson3-11/+26
The executable bit will not be detected (and therefore will not be set) for paths in a repository with `core.filemode` set to false, though the users may still wish to add files as executable for compatibility with other users who _do_ have `core.filemode` functionality. For example, Windows users adding shell scripts may wish to add them as executable for compatibility with users on non-Windows. Although this can be done with a plumbing command (`git update-index --add --chmod=+x foo`), teaching the `git-add` command allows users to set a file executable with a command that they're already familiar with. Signed-off-by: Edward Thomson <ethomson@edwardthomson.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06Merge branch 'sb/submodule-helper-relative-path'Libravatar Junio C Hamano1-0/+12
A bash-ism "local" has been removed from "git submodule" scripted Porcelain. * sb/submodule-helper-relative-path: submodule: remove bashism from shell script
2016-06-06Merge branch 'sb/submodule-helper-list-signal-unmatch-via-exit-status'Libravatar Junio C Hamano1-3/+1
The way how "submodule--helper list" signals unmatch error to its callers has been updated. * sb/submodule-helper-list-signal-unmatch-via-exit-status: submodule--helper: offer a consistent API
2016-06-06builtin/apply: remove misleading comment on lock_file fieldLibravatar Junio C Hamano1-4/+1
Just like pointer field like prefix, the piece of memory pointed at by lock_file field is not owned by the apply_state structure. It is true that the caller needs to be careful about the lifetime rule for lockfile instances, but that is none of this API's business. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-06receive-pack: send auto-gc output over sideband 2Libravatar Lukas Fleischer1-2/+13
Redirect auto-gc output to the sideband such that it is visible to all clients. As a side effect, all auto-gc error messages are now prefixed with "remote: " before being printed to stderr on the client-side which makes it easier to understand that those error messages originate from the server. Signed-off-by: Lukas Fleischer <lfleischer@lfos.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-03Merge branch 'rs/apply-name-terminate'Libravatar Junio C Hamano1-2/+2
Code clean-up. * rs/apply-name-terminate: apply: remove unused parameters from name_terminate()
2016-06-03Merge branch 'rs/patch-id-use-skip-prefix'Libravatar Junio C Hamano1-13/+10
Code clean-up. * rs/patch-id-use-skip-prefix: patch-id: use starts_with() and skip_prefix()
2016-06-03builtin/apply: move 'newfd' global into 'struct apply_state'Libravatar Christian Couder1-4/+5
To libify the apply functionality the 'newfd' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-03builtin/apply: add 'lock_file' pointer into 'struct apply_state'Libravatar Christian Couder1-4/+15
We cannot have a 'struct lock_file' allocated on the stack, as lockfile.c keeps a linked list of all created lock_file structures. Also 'struct apply_state' users might later want the same 'struct lock_file' instance to be reused by different series of calls to the apply api. So let's add a 'struct lock_file *lock_file' pointer into 'struct apply_state' and have the user of 'struct apply_state' allocate memory for the actual 'struct lock_file' instance. Let's also add an argument to init_apply_state(), so that the caller can easily supply a pointer to the allocated instance. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-03rev-list: disable bitmaps when "-n" is used with listing objectsLibravatar Jeff King1-1/+2
You can ask rev-list to use bitmaps to speed up an --objects traversal, which should generally give you your answers much faster. Likewise, you can ask rev-list to limit such a traversal with `-n`, in which case we'll show only a limited set of commits (and only the tree and commit objects directly reachable from those commits). But if you do both together, the results are nonsensical. We end up limiting any fallback traversal we do to _find_ the bitmaps, but the actual set of objects we output will be picked arbitrarily from the union of any bitmaps we do find, and will involve the objects of many more commits. It's possible that somebody might want this as a "show me what you can, but limit the amount of work you do" flag. But as with the prior commit clamping "--count", the results are basically non-deterministic; you'll get the values from some commits between `n` and the total number, and you can't tell which. And unlike the `--count` case, we can't easily generate the "real" value from the bitmap values (you can't just walk back `-n` commits and subtract out the reachable objects from the boundary commits; the bitmaps for `X` record its total reachability, so you don't know which objects are directly from `X` itself, which from `X^`, and so on). So let's just fallback to the non-bitmap code path in this case, so we always give a sane answer. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-03rev-list: "adjust" results of "--count --use-bitmap-index -n"Libravatar Jeff King1-0/+3
If you ask rev-list for: git rev-list --count --use-bitmap-index HEAD we optimize out the actual traversal and just give you the number of bits set in the commit bitmap. This is faster, which is good. But if you ask to limit the size of the traversal, like: git rev-list --count --use-bitmap-index -n 100 HEAD we'll still output the full bitmapped number we found. On the surface, that might even seem OK. You explicitly asked to use the bitmap index, and it was cheap to compute the real answer, so we gave it to you. But there's something much more complicated going on under the hood. If we don't have a bitmap directly for HEAD, then we have to actually traverse backwards, looking for a bitmapped commit. And _that_ traversal is bounded by our `-n` count. This is a good thing, because it bounds the work we have to do, which is probably what the user wanted by asking for `-n`. But now it makes the output quite confusing. You might get many values: - your `-n` value, if we walked back and never found a bitmap (or fewer if there weren't that many commits) - the actual full count, if we found a bitmap root for every path of our traversal with in the `-n` limit - any number in between! We might have walked back and found _some_ bitmaps, but then cut off the traversal early with some commits not accounted for in the result. So you cannot even see a value higher than your `-n` and say "OK, bitmaps kicked in, this must be the real full count". The only sane thing is for git to just clamp the value to a maximum of the `-n` value, which means we should output the exact same results whether bitmaps are in use or not. The test in t5310 demonstrates this by using `-n 1`. Without this patch we fail in the full-bitmap case (where we do not have to traverse at all) but _not_ in the partial-bitmap case (where we have to walk down to find an actual bitmap). With this patch, both cases just work. I didn't implement the crazy in-between case, just because it's complicated to set up, and is really a subset of the full-count case, which we do cover. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-02pathspec: rename free_pathspec() to clear_pathspec()Libravatar Junio C Hamano3-5/+5
The function takes a pointer to a pathspec structure, and releases the resources held by it, but does not free() the structure itself. Such a function should be called "clear", not "free". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01submodule: remove bashism from shell scriptLibravatar Stefan Beller1-0/+12
Junio pointed out `relative_path` was using bashisms via the local variables. As the longer term goal is to rewrite most of the submodule code in C, do it now. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01submodule--helper: offer a consistent APILibravatar Stefan Beller1-3/+1
In 48308681 (2016-02-29, git submodule update: have a dedicated helper for cloning), the helper communicated errors back only via exit code, and dance with printing '#unmatched' in case of error was left to git-submodule.sh as it uses the output of the helper and pipes it into shell commands. This change makes the helper consistent by never printing '#unmatched' in the helper but always handling these piping issues in the actual shell script. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move applying patches into apply_all_patches()Libravatar Christian Couder1-58/+71
To libify the apply functionality we should provide a function to apply many patches. Let's move the code to do that into a new apply_all_patches() function. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'state' check into check_apply_state()Libravatar Christian Couder1-23/+29
To libify the apply functionality we should provide a function to check that the values in a 'struct apply_state' instance are coherent. Let's move the code to do that into a new check_apply_state() function. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'symlink_changes' global into 'struct apply_state'Libravatar Christian Couder1-22/+28
To libify the apply functionality the 'symlink_changes' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'fn_table' global into 'struct apply_state'Libravatar Christian Couder1-22/+25
To libify the apply functionality the 'fn_table' variable should not be static and global to the file. Let's move it into 'struct apply_state'. As fn_table is cleared at the end of apply_patch(), it is not necessary to clear it in clear_apply_state(). Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'state_linenr' global into 'struct apply_state'Libravatar Christian Couder1-35/+36
To libify the apply functionality the 'state_linenr' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'max_change' and 'max_len' into 'struct apply_state'Libravatar Christian Couder1-24/+25
To libify the apply functionality the 'max_change' and 'max_len' variables should not be static and global to the file. Let's move them into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'ws_ignore_action' into 'struct apply_state'Libravatar Christian Couder1-17/+20
To libify the apply functionality the 'ws_ignore_action' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'ws_error_action' into 'struct apply_state'Libravatar Christian Couder1-28/+33
To libify the apply functionality the 'ws_error_action' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'applied_after_fixing_ws' into 'struct apply_state'Libravatar Christian Couder1-5/+5
To libify the apply functionality the 'applied_after_fixing_ws' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'squelch_whitespace_errors' into 'struct apply_state'Libravatar Christian Couder1-11/+11
To libify the apply functionality the 'squelch_whitespace_errors' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: remove whitespace_option arg from set_default_whitespace_mode()Libravatar Christian Couder1-5/+4
A previous change has move the whitespace_option variable from cmd_apply into 'struct apply_state', so that we can now avoid passing it separately to set_default_whitespace_mode(). Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'whitespace_option' into 'struct apply_state'Libravatar Christian Couder1-7/+6
This will enable further refactoring, and it is more coherent and simpler if all the option_parse_*() functions are passed a 'struct apply_state' instance in opt->value. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'whitespace_error' global into 'struct apply_state'Libravatar Christian Couder1-13/+15
To libify the apply functionality the 'whitespace_error' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'root' global into 'struct apply_state'Libravatar Christian Couder1-33/+49
To libify the apply functionality the 'root' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'p_value_known' global into 'struct apply_state'Libravatar Christian Couder1-5/+4
To libify the apply functionality the 'p_value_known' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'p_value' global into 'struct apply_state'Libravatar Christian Couder1-52/+99
To libify the apply functionality the 'p_value' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'has_include' global into 'struct apply_state'Libravatar Christian Couder1-3/+3
To libify the apply functionality the 'has_include' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'limit_by_name' global into 'struct apply_state'Libravatar Christian Couder1-10/+16
To libify the apply functionality the 'limit_by_name' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-01builtin/apply: move 'patch_input_file' global into 'struct apply_state'Libravatar Christian Couder1-10/+17
To libify the apply functionality the 'patch_input_file' variable should not be static and global to the file. Let's move it into 'struct apply_state'. Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>