summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2018-04-10builtin/config.c: treat type specifiers singularlyLibravatar Taylor Blau1-27/+22
Internally, we represent `git config`'s type specifiers as a bitset using OPT_BIT. 'bool' is 1<<0, 'int' is 1<<1, and so on. This technique allows for the representation of multiple type specifiers in the `int types` field, but this multi-representation is left unused. In fact, `git config` will not accept multiple type specifiers at a time, as indicated by: $ git config --int --bool some.section error: only one type at a time. This patch uses `OPT_SET_INT` to prefer the _last_ mentioned type specifier, so that the above command would instead be valid, and a synonym of: $ git config --bool some.section This change is motivated by two urges: (1) it does not make sense to represent a singular type specifier internally as a bitset, only to complain when there are multiple bits in the set. `OPT_SET_INT` is more well-suited to this task than `OPT_BIT` is. (2) a future patch will introduce `--type=<type>`, and we would like not to complain in the following situation: $ git config --int --type=int Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-28Merge branch 'pc/submodule-helper'Libravatar Junio C Hamano1-1/+1
Hotfix. * pc/submodule-helper: submodule deinit: handle non existing pathspecs gracefully
2018-03-27submodule deinit: handle non existing pathspecs gracefullyLibravatar Stefan Beller1-1/+1
This fixes a regression introduced in 2e612731b5 (submodule: port submodule subcommand 'deinit' from shell to C, 2018-01-15), when handling pathspecs that do not exist gracefully. This restores the historic behavior of reporting the pathspec as unknown and returning instead of reporting a bug. Reported-by: Peter Oberndorfer <kumbayo84@arcor.de> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-21Merge branch 'rj/warning-uninitialized-fix'Libravatar Junio C Hamano1-1/+1
Compilation fix. * rj/warning-uninitialized-fix: read-cache: fix an -Wmaybe-uninitialized warning -Wuninitialized: remove some 'init-self' workarounds
2018-03-21Merge branch 'jt/transfer-fsck-with-promissor'Libravatar Junio C Hamano1-2/+4
The transfer.fsckobjects configuration tells "git fetch" to validate the data and connected-ness of objects in the received pack; the code to perform this check has been taught about the narrow clone's convention that missing objects that are reachable from objects in a pack that came from a promissor remote is OK. * jt/transfer-fsck-with-promissor: fetch-pack: do not check links for partial fetch index-pack: support checking objects but not links
2018-03-21Merge branch 'ma/skip-writing-unchanged-index'Libravatar Junio C Hamano5-26/+17
Internal API clean-up to allow write_locked_index() optionally skip writing the in-core index when it is not modified. * ma/skip-writing-unchanged-index: write_locked_index(): add flag to avoid writing unchanged index
2018-03-21Merge branch 'ma/config-page-only-in-list-mode'Libravatar Junio C Hamano1-0/+10
In a way similar to how "git tag" learned to honor the pager setting only in the list mode, "git config" learned to ignore the pager setting when it is used for setting values (i.e. when the purpose of the operation is not to "show"). * ma/config-page-only-in-list-mode: config: change default of `pager.config` to "on" config: respect `pager.config` in list/get-mode only t7006: add tests for how git config paginates
2018-03-20-Wuninitialized: remove some 'init-self' workaroundsLibravatar Ramsay Jones1-1/+1
The 'self-initialised' variables construct (ie <type> var = var;) has been used to silence gcc '-W[maybe-]uninitialized' warnings. This has, unfortunately, caused MSVC to issue 'uninitialized variable' warnings. Also, using clang static analysis causes complaints about an 'Assigned value is garbage or undefined'. There are six such constructs in the current codebase. Only one of the six causes gcc to issue a '-Wmaybe-uninitialized' warning (which will be addressed elsewhere). The remaining five 'init-self' gcc workarounds are noted below, along with the commit which introduced them: 1. builtin/rev-list.c: 'reaches' and 'all', see commit 457f08a030 ("git-rev-list: add --bisect-vars option.", 2007-03-21). 2. merge-recursive.c:2064 'mrtree', see commit f120ae2a8e ("merge- recursive.c: mrtree in merge() is not used before set", 2007-10-29). 3. fast-import.c:3023 'oe', see commit 85c62395b1 ("fast-import: let importers retrieve blobs", 2010-11-28). 4. fast-import.c:3006 'oe', see commit 28c7b1f7b7 ("fast-import: add a get-mark command", 2015-07-01). Remove the 'self-initialised' variable constructs noted above. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-15index-pack: support checking objects but not linksLibravatar Jonathan Tan1-2/+4
The index-pack command currently supports the --check-self-contained-and-connected argument, for internal use only, that instructs it to only check for broken links and not broken objects. For partial clones, we need the inverse, so add a --fsck-objects argument that checks for broken objects and not broken links, also for internal use only. This will be used by fetch-pack in a subsequent patch. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-14Merge branch 'nd/parseopt-completion'Libravatar Junio C Hamano20-28/+42
Teach parse-options API an option to help the completion script, and make use of the mechanism in command line completion. * nd/parseopt-completion: (45 commits) completion: more subcommands in _git_notes() completion: complete --{reuse,reedit}-message= for all notes subcmds completion: simplify _git_notes completion: don't set PARSE_OPT_NOCOMPLETE on --rerere-autoupdate completion: use __gitcomp_builtin in _git_worktree completion: use __gitcomp_builtin in _git_tag completion: use __gitcomp_builtin in _git_status completion: use __gitcomp_builtin in _git_show_branch completion: use __gitcomp_builtin in _git_rm completion: use __gitcomp_builtin in _git_revert completion: use __gitcomp_builtin in _git_reset completion: use __gitcomp_builtin in _git_replace remote: force completing --mirror= instead of --mirror completion: use __gitcomp_builtin in _git_remote completion: use __gitcomp_builtin in _git_push completion: use __gitcomp_builtin in _git_pull completion: use __gitcomp_builtin in _git_notes completion: use __gitcomp_builtin in _git_name_rev completion: use __gitcomp_builtin in _git_mv completion: use __gitcomp_builtin in _git_merge_base ...
2018-03-14Merge branch 'nd/object-allocation-comments'Libravatar Junio C Hamano4-0/+4
Code doc update. * nd/object-allocation-comments: object.h: realign object flag allocation comment object.h: update flag allocation comment
2018-03-14Merge branch 'nd/worktree-move'Libravatar Junio C Hamano1-0/+220
"git worktree" learned move and remove subcommands. * nd/worktree-move: t2028: fix minor error and issues in newly-added "worktree move" tests worktree remove: allow it when $GIT_WORK_TREE is already gone worktree remove: new command worktree move: refuse to move worktrees with submodules worktree move: accept destination as directory worktree move: new command worktree.c: add update_worktree_location() worktree.c: add validate_worktree()
2018-03-08Merge branch 'ab/gc-auto-in-commit'Libravatar Junio C Hamano1-0/+2
"git commit" used to run "gc --auto" near the end, which was lost when the command was reimplemented in C by mistake. * ab/gc-auto-in-commit: commit: run git gc --auto just before the post-commit hook
2018-03-08Merge branch 'rv/grep-cleanup'Libravatar Junio C Hamano1-13/+20
Threaded "git grep" has been optimized to avoid allocation in code section that is covered under a mutex. * rv/grep-cleanup: grep: simplify grep_oid and grep_file grep: move grep_source_init outside critical section
2018-03-08Merge branch 'jh/status-no-ahead-behind'Libravatar Junio C Hamano2-1/+8
"git status" can spend a lot of cycles to compute the relation between the current branch and its upstream, which can now be disabled with "--no-ahead-behind" option. * jh/status-no-ahead-behind: status: support --no-ahead-behind in long format status: update short status to respect --no-ahead-behind status: add --[no-]ahead-behind to status and commit for V2 format. stat_tracking_info: return +1 when branches not equal
2018-03-06Merge branch 'bw/c-plus-plus'Libravatar Junio C Hamano21-253/+253
Avoid using identifiers that clash with C++ keywords. Even though it is not a goal to compile Git with C++ compilers, changes like this help use of code analysis tools that targets C++ on our codebase. * bw/c-plus-plus: (37 commits) replace: rename 'new' variables trailer: rename 'template' variables tempfile: rename 'template' variables wrapper: rename 'template' variables environment: rename 'namespace' variables diff: rename 'template' variables environment: rename 'template' variables init-db: rename 'template' variables unpack-trees: rename 'new' variables trailer: rename 'new' variables submodule: rename 'new' variables split-index: rename 'new' variables remote: rename 'new' variables ref-filter: rename 'new' variables read-cache: rename 'new' variables line-log: rename 'new' variables imap-send: rename 'new' variables http: rename 'new' variables entry: rename 'new' variables diffcore-delta: rename 'new' variables ...
2018-03-06Merge branch 'jk/cached-commit-buffer'Libravatar Junio C Hamano1-1/+1
Code clean-up. * jk/cached-commit-buffer: revision: drop --show-all option commit: drop uses of get_cached_commit_buffer()
2018-03-06Merge branch 'jc/allow-ff-merging-kept-tags'Libravatar Junio C Hamano1-4/+39
Since Git 1.7.9, "git merge" defaulted to --no-ff (i.e. even when the side branch being merged is a descendant of the current commit, create a merge commit instead of fast-forwarding) when merging a tag object. This was appropriate default for integrators who pull signed tags from their downstream contributors, but caused an unnecessary merges when used by downstream contributors who habitually "catch up" their topic branches with tagged releases from the upstream. Update "git merge" to default to --no-ff only when merging a tag object that does *not* sit at its usual place in refs/tags/ hierarchy, and allow fast-forwarding otherwise, to mitigate the problem. * jc/allow-ff-merging-kept-tags: merge: allow fast-forward when merging a tracked tag
2018-03-06Merge branch 'nd/rebase-show-current-patch'Libravatar Junio C Hamano1-4/+43
The new "--show-current-patch" option gives an end-user facing way to get the diff being applied when "git rebase" (and "git am") stops with a conflict. * nd/rebase-show-current-patch: rebase: introduce and use pseudo-ref REBASE_HEAD rebase: add --show-current-patch am: add --show-current-patch
2018-03-06Merge branch 'ab/fetch-prune'Libravatar Junio C Hamano1-8/+46
Clarify how configured fetch refspecs interact with the "--prune" option of "git fetch", and also add a handy short-hand for getting rid of stale tags that are locally held. * ab/fetch-prune: fetch: make the --prune-tags work with <url> fetch: add a --prune-tags option and fetch.pruneTags config fetch tests: add scaffolding for the new fetch.pruneTags git-fetch & config doc: link to the new PRUNING section git remote doc: correct dangerous lies about what prune does git fetch doc: add a new section to explain the ins & outs of pruning fetch tests: fetch <url> <spec> as well as fetch [<remote>] fetch tests: expand case/esac for later change fetch tests: double quote a variable for interpolation fetch tests: test --prune and refspec interaction fetch tests: add a tag to be deleted to the pruning tests fetch tests: re-arrange arguments for future readability fetch tests: refactor in preparation for testing tag pruning remote: add a macro for "refs/tags/*:refs/tags/*" fetch: stop accessing "remote" variable indirectly fetch: trivially refactor assignment to ref_nr fetch: don't redundantly NULL something calloc() gave us
2018-03-06Merge branch 'sm/mv-dry-run-update'Libravatar Junio C Hamano1-2/+1
Code clean-up. * sm/mv-dry-run-update: mv: remove unneeded 'if (!show_only)' t7001: add test case for --dry-run
2018-03-06Merge branch 'nm/tag-edit'Libravatar Junio C Hamano1-2/+9
"git tag" learned an explicit "--edit" option that allows the message given via "-m" and "-F" to be further edited. * nm/tag-edit: tag: add --edit option
2018-03-06object.h: update flag allocation commentLibravatar Nguyễn Thái Ngọc Duy4-0/+4
Since the "flags" is shared, it's a good idea to keep track of who uses what bit. When we need to use more flags in library code, we can be sure it won't be re-used for another purpose by some caller. While at there, fix the location of "5" (should be in a different column than "4" two lines down) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-01write_locked_index(): add flag to avoid writing unchanged indexLibravatar Martin Ågren5-26/+17
We have several callers like if (active_cache_changed && write_locked_index(...)) handle_error(); rollback_lock_file(...); where the final rollback is needed because "!active_cache_changed" shortcuts the if-expression. There are also a few variants of this, including some if-else constructs that make it more clear when the explicit rollback is really needed. Teach `write_locked_index()` to take a new flag SKIP_IF_UNCHANGED and simplify the callers. Leave the most complicated of the callers (in builtin/update-index.c) unchanged. Rewriting it to use this new flag would end up duplicating logic. We could have made the new flag behave the other way round ("FORCE_WRITE"), but that could break existing users behind their backs. Let's take the more conservative approach. We can still migrate existing callers to use our new flag. Later we might even be able to flip the default, possibly without entirely ignoring the risk to in-flight or out-of-tree topics. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-01commit: run git gc --auto just before the post-commit hookLibravatar Ævar Arnfjörð Bjarmason1-0/+2
Change the behavior of git-commit back to what it was back in d4bb43ee27 ("Invoke "git gc --auto" from commit, merge, am and rebase.", 2007-09-05) when it was git-commit.sh. Shortly afterwards in f5bbc3225c ("Port git commit to C.", 2007-11-08) when it was ported to C, the "git gc --auto" invocation went away. Since that unintended regression, git gc --auto only ran for git-am, git-merge, git-fetch, and git-receive-pack. It was possible to write a script that would "git commit" a lot of data locally, and gc would never run. One such repository that was locally committing generated zone file changes had grown to a size of ~60GB before a daily cronjob was added to "git gc", bringing it down to less than 1GB. This will make such cases work without intervention. I think fixing such pathological cases where the repository will grow forever is a worthwhile trade-off for spending a couple of milliseconds calling "git gc --auto" (in the common cases where it doesn't do anything). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-28Merge branch 'es/worktree-add-post-checkout-hook'Libravatar Junio C Hamano1-3/+17
"git worktree add" learned to run the post-checkout hook, just like "git clone" runs it upon the initial checkout. * es/worktree-add-post-checkout-hook: worktree: add: fix 'post-checkout' not knowing new worktree location
2018-02-28Merge branch 'nd/am-quit'Libravatar Junio C Hamano1-2/+10
"git am" has learned the "--quit" option, in addition to the existing "--abort" option; having the pair mirrors a few other commands like "rebase" and "cherry-pick". * nd/am-quit: am: support --quit
2018-02-27Merge branch 'ab/commit-m-with-fixup' into maintLibravatar Junio C Hamano1-3/+5
"git commit --fixup" did not allow "-m<message>" option to be used at the same time; allow it to annotate resulting commit with more text. * ab/commit-m-with-fixup: commit: add support for --fixup <commit> -m"<extra message>" commit doc: document that -c, -C, -F and --fixup with -m error
2018-02-27Merge branch 'nd/ita-wt-renames-in-status' into maintLibravatar Junio C Hamano1-1/+1
"git status" after moving a path in the working tree (hence making it appear "removed") and then adding with the -N option (hence making that appear "added") detected it as a rename, but did not report the old and new pathnames correctly. * nd/ita-wt-renames-in-status: wt-status.c: handle worktree renames wt-status.c: rename rename-related fields in wt_status_change_data wt-status.c: catch unhandled diff status codes wt-status.c: coding style fix Use DIFF_DETECT_RENAME for detect_rename assignments t2203: test status output with porcelain v2 format
2018-02-27Merge branch 'sb/describe-blob'Libravatar Junio C Hamano1-1/+1
"git describe $garbage" stopped giving any errors when the garbage happens to be a string with 40 hexadecimal letters. * sb/describe-blob: describe: confirm that blobs actually exist
2018-02-27Merge branch 'rs/check-ignore-multi'Libravatar Junio C Hamano1-1/+2
"git check-ignore" with multiple paths got confused when one is a file and the other is a directory, which has been fixed. * rs/check-ignore-multi: check-ignore: fix mix of directories and other file types
2018-02-27Merge branch 'js/packet-read-line-check-null'Libravatar Junio C Hamano1-1/+1
Some low level protocol codepath could crash when they get an unexpected flush packet, which is now fixed. * js/packet-read-line-check-null: always check for NULL return from packet_read_line() correct error messages for NULL packet_read_line()
2018-02-27Merge branch 'jc/blame-missing-path'Libravatar Junio C Hamano1-6/+14
"git blame HEAD COPYING" in a bare repository failed to run, while "git blame HEAD -- COPYING" run just fine. This has been corrected. * jc/blame-missing-path: blame: tighten command line parser
2018-02-23grep: simplify grep_oid and grep_fileLibravatar Rasmus Villemoes1-4/+2
In the NO_PTHREADS or !num_threads case, this doesn't change anything. In the threaded case, note that grep_source_init duplicates its third argument, so there is no need to keep [path]buf.buf alive across the call of add_work(). Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-23grep: move grep_source_init outside critical sectionLibravatar Rasmus Villemoes1-9/+18
grep_source_init typically does three strdup()s, and in the threaded case, the call from add_work() happens while holding grep_mutex. We can thus reduce the time we hold grep_mutex by moving the grep_source_init() call out of add_work(), and simply have add_work() copy the initialized structure to the available slot in the todo array. This also simplifies the prototype of add_work(), since it no longer needs to duplicate all the parameters of grep_source_init(). In the callers of add_work(), we get to reduce the amount of code duplicated in the threaded and non-threaded cases slightly (avoiding repeating the long "GREP_SOURCE_OID, pathbuf.buf, path, oid" argument list); a subsequent cleanup patch will make that even more so. Signed-off-by: Rasmus Villemoes <rv@rasmusvillemoes.dk> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-22commit: drop uses of get_cached_commit_buffer()Libravatar Jeff King1-1/+1
The "--show-all" revision option shows UNINTERESTING commits. Some of these commits may be unparsed when we try to show them (since we may or may not need to walk their parents to fulfill the request). Commit 3131b71301 (Add "--show-all" revision walker flag for debugging, 2008-02-09) resolved this by just skipping pretty-printing for commits without their object contents cached, saying: Because we now end up listing commits we may not even have been parsed at all "show_log" and "show_commit" need to protect against commits that don't have a commit buffer entry. That was the easy fix to avoid the pretty-printer segfaulting, but: 1. It doesn't work for all formats. E.g., --oneline prints the oid for each such commit but not a trailing newline, leading to jumbled output. 2. It only affects some commits, depending on whether we happened to parse them or not (so if they were at the tip of an UNINTERESTING starting point, or if we happened to traverse over them, you'd see more data). 3. It unncessarily ties the decision to show the verbose header to whether the commit buffer was cached. That makes it harder to change the logic around caching (e.g., if we could traverse without actually loading the full commit objects). These days it's safe to feed such a commit to the pretty-print code. Since be5c9fb904 (logmsg_reencode: lazily load missing commit buffers, 2013-01-26), we'll load it on demand in such a case. So let's just always show the verbose headers. This does change the behavior of plumbing, but: a. The --show-all option was explicitly introduced as a debugging aid, and was never documented (and has rarely even been mentioned on the list by git devs). b. Avoiding the commits was already not deterministic due to (2) above. So the caller might have seen full headers for these commits anyway, and would need to be prepared for it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-22replace: rename 'new' variablesLibravatar Brandon Williams1-17/+17
Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-22init-db: rename 'template' variablesLibravatar Brandon Williams1-15/+15
Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-22remote: rename 'new' variablesLibravatar Brandon Williams1-33/+33
Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-22reflog: rename 'new' variablesLibravatar Brandon Williams1-4/+4
Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-22pack-redundant: rename 'new' variablesLibravatar Brandon Williams1-27/+27
Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-22help: rename 'new' variablesLibravatar Brandon Williams1-5/+5
Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-22checkout: rename 'new' variablesLibravatar Brandon Williams1-98/+98
Rename C++ keyword in order to bring the codebase closer to being able to be compiled with a C++ compiler. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-21config: change default of `pager.config` to "on"Libravatar Martin Ågren1-1/+1
This is similar to ff1e72483 (tag: change default of `pager.tag` to "on", 2017-08-02) and is safe now that we do not consider `pager.config` at all when we are not listing or getting configuration. This change will help with listing large configurations, but will not hurt users of `git config --edit` as it would have before the previous commit. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-21config: respect `pager.config` in list/get-mode onlyLibravatar Martin Ågren1-0/+10
Similar to de121ffe5 (tag: respect `pager.tag` in list-mode only, 2017-08-02), use the DELAY_PAGER_CONFIG-mechanism to only respect `pager.config` when we are listing or "get"ing config. We have several getters and some are guaranteed to give at most one line of output. Paging all getters including those could be convenient from a documentation point-of-view. The downside would be that a misconfigured or not so modern pager might wait for user interaction before terminating. Let's instead respect the config for precisely those getters which may produce more than one line of output. `--get-urlmatch` may or may not produce multiple lines of output, depending on the exact usage. Let's not try to recognize the two modes, but instead make `--get-urlmatch` always respect the config. Analyzing the detailed usage might be trivial enough here, but could establish a precedent that we will never be able to enforce throughout the codebase and that will just open a can of worms. This fixes the failing test added in the previous commit. Also adapt the test for whether `git config foo.bar bar` and `git config --get foo.bar` respects `pager.config`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-21Merge branch 'gs/rebase-allow-empty-message'Libravatar Junio C Hamano1-0/+2
"git rebase" learned to take "--allow-empty-message" option. * gs/rebase-allow-empty-message: rebase: add --allow-empty-message option
2018-02-21Merge branch 'nd/format-patch-stat-width'Libravatar Junio C Hamano1-1/+6
"git format-patch" learned to give 72-cols to diffstat, which is consistent with other line length limits the subcommand uses for its output meant for e-mails. * nd/format-patch-stat-width: format-patch: reduce patch diffstat width to 72 format-patch: keep cover-letter diffstat wrapped in 72 columns
2018-02-16merge: allow fast-forward when merging a tracked tagLibravatar Junio C Hamano1-4/+39
Long time ago at fab47d05 ("merge: force edit and no-ff mode when merging a tag object", 2011-11-07), "git merge" was made to always create a merge commit when merging a tag, even when the side branch being merged is a descendant of the current branch. This default is good for merges made by upstream maintainers to integrate work signed by downstream contributors, but will leave pointless no-ff merges when downstream contributors pull a newer release tag to make their long-running topic branches catch up with the upstream. When there is no local work left on the topic, such a merge should simply fast-forward to the commit pointed at by the release tag. Update the default (again) for "git merge" that merges a tag object to (1) --no-ff (i.e. create a merge commit even when side branch fast forwards) if the tag being merged is not at its expected place in refs/tags/ hierarchy and (2) --ff (i.e. allow fast-forward update when able) otherwise. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-15Merge branch 'jk/abort-clone-with-existing-dest' into maintLibravatar Junio C Hamano1-7/+24
"git clone $there $here" is allowed even when here directory exists as long as it is an empty directory, but the command incorrectly removed it upon a failure of the operation. * jk/abort-clone-with-existing-dest: clone: do not clean up directories we didn't create clone: factor out dir_exists() helper t5600: modernize style t5600: fix outdated comment about unborn HEAD
2018-02-15Merge branch 'rs/lose-leak-pending' into maintLibravatar Junio C Hamano1-12/+1
API clean-up around revision traversal. * rs/lose-leak-pending: commit: remove unused function clear_commit_marks_for_object_array() revision: remove the unused flag leak_pending checkout: avoid using the rev_info flag leak_pending bundle: avoid using the rev_info flag leak_pending bisect: avoid using the rev_info flag leak_pending object: add clear_commit_marks_all() ref-filter: use clear_commit_marks_many() in do_merge_filter() commit: use clear_commit_marks_many() in remove_redundant() commit: avoid allocation in clear_commit_marks_many()