summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2018-09-24Merge branch 'bw/protocol-v2'Libravatar Junio C Hamano1-0/+2
Doc fix. * bw/protocol-v2: config: document value 2 for protocol.version
2018-09-20Merge branch 'ab/fetch-tags-noclobber'Libravatar Junio C Hamano2-3/+3
The rules used by "git push" and "git fetch" to determine if a ref can or cannot be updated were inconsistent; specifically, fetching to update existing tags were allowed even though tags are supposed to be unmoving anchoring points. "git fetch" was taught to forbid updates to existing tags without the "--force" option. This is a backward incompatible change but in a good way; it may still need to be treated carefully. * ab/fetch-tags-noclobber: fetch doc: correct grammar in --force docs push doc: add spacing between two words
2018-09-20Merge branch 'bp/checkout-new-branch-optim'Libravatar Junio C Hamano1-1/+1
"git checkout -b newbranch [HEAD]" should not have to do as much as checking out a commit different from HEAD. An attempt is made to optimize this special case. * bp/checkout-new-branch-optim: config doc: add missing list separator for checkout.optimizeNewBranch
2018-09-20fetch doc: correct grammar in --force docsLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Correct a grammar error (saying "the receiving" made no sense) in the recently landed documentation added in my 0bc8d71b99 ("fetch: stop clobbering existing tags without --force", 2018-08-31) by rephrasing the sentence. Also correct 'fetching work the same way' by s/work/&s/; Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-19push doc: add spacing between two wordsLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Fix a formatting error introduced in my recently landed fe802bd21e ("push doc: correct lies about how push refspecs work", 2018-08-31). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-19config doc: add missing list separator for checkout.optimizeNewBranchLibravatar Ævar Arnfjörð Bjarmason1-1/+1
The documentation added in fa655d8411 ("checkout: optimize "git checkout -b <new_branch>"", 2018-08-16) didn't add the double-colon needed for the labeled list separator, as a result the added documentation all got squashed into one paragraph. Fix that by adding the list separator. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-17Merge branch 'ab/fetch-tags-noclobber'Libravatar Junio C Hamano4-24/+94
The rules used by "git push" and "git fetch" to determine if a ref can or cannot be updated were inconsistent; specifically, fetching to update existing tags were allowed even though tags are supposed to be unmoving anchoring points. "git fetch" was taught to forbid updates to existing tags without the "--force" option. * ab/fetch-tags-noclobber: fetch: stop clobbering existing tags without --force fetch: document local ref updates with/without --force push doc: correct lies about how push refspecs work push doc: move mention of "tag <tag>" later in the prose push doc: remove confusing mention of remote merger fetch tests: add a test for clobbering tag behavior push tests: use spaces in interpolated string push tests: make use of unused $1 in test description fetch: change "branch" to "reference" in --force -h output
2018-09-17Merge branch 'es/worktree-forced-ops-fix'Libravatar Junio C Hamano2-3/+11
Fix a bug in which the same path could be registered under multiple worktree entries if the path was missing (for instance, was removed manually). Also, as a convenience, expand the number of cases in which --force is applicable. * es/worktree-forced-ops-fix: doc-diff: force worktree add worktree: delete .git/worktrees if empty after 'remove' worktree: teach 'remove' to override lock when --force given twice worktree: teach 'move' to override lock when --force given twice worktree: teach 'add' to respect --force for registered but missing path worktree: disallow adding same path multiple times worktree: prepare for more checks of whether path can become worktree worktree: generalize delete_git_dir() to reduce code duplication worktree: move delete_git_dir() earlier in file for upcoming new callers worktree: don't die() in library function find_worktree()
2018-09-17Merge branch 'sg/doc-trace-appends'Libravatar Junio C Hamano1-2/+2
Docfix. * sg/doc-trace-appends: Documentation/git.txt: clarify that GIT_TRACE=/path appends
2018-09-17Merge branch 'jk/diff-rendered-docs'Libravatar Junio C Hamano2-9/+32
Dev doc update. * jk/diff-rendered-docs: Revert "doc/Makefile: drop doc-diff worktree and temporary files on "make clean"" doc/Makefile: drop doc-diff worktree and temporary files on "make clean" doc-diff: add --clean mode to remove temporary working gunk doc-diff: fix non-portable 'man' invocation doc-diff: always use oids inside worktree SubmittingPatches: mention doc-diff
2018-09-17Merge branch 'tg/rerere-doc-updates'Libravatar Junio C Hamano2-0/+10
Clarify a part of technical documentation for rerere. * tg/rerere-doc-updates: rerere: add note about files with existing conflict markers rerere: mention caveat about unmatched conflict markers
2018-09-17Merge branch 'es/format-patch-rangediff'Libravatar Junio C Hamano1-0/+19
"git format-patch" learned a new "--range-diff" option to explain the difference between this version and the previous attempt in the cover letter (or after the tree-dashes as a comment). * es/format-patch-rangediff: format-patch: allow --range-diff to apply to a lone-patch format-patch: add --creation-factor tweak for --range-diff format-patch: teach --range-diff to respect -v/--reroll-count format-patch: extend --range-diff to accept revision range format-patch: add --range-diff option to embed diff in cover letter range-diff: relieve callers of low-level configuration burden range-diff: publish default creation factor range-diff: respect diff_option.file rather than assuming 'stdout'
2018-09-17Merge branch 'es/format-patch-interdiff'Libravatar Junio C Hamano1-0/+10
"git format-patch" learned a new "--interdiff" option to explain the difference between this version and the previous atttempt in the cover letter (or after the tree-dashes as a comment). * es/format-patch-interdiff: format-patch: allow --interdiff to apply to a lone-patch log-tree: show_log: make commentary block delimiting reusable interdiff: teach show_interdiff() to indent interdiff format-patch: teach --interdiff to respect -v/--reroll-count format-patch: add --interdiff option to embed diff in cover letter format-patch: allow additional generated content in make_cover_letter()
2018-09-17Merge branch 'cc/delta-islands'Libravatar Junio C Hamano3-0/+121
Lift code from GitHub to restrict delta computation so that an object that exists in one fork is not made into a delta against another object that does not appear in the same forked repository. * cc/delta-islands: pack-objects: move 'layer' into 'struct packing_data' pack-objects: move tree_depth into 'struct packing_data' t5320: tests for delta islands repack: add delta-islands support pack-objects: add delta-islands support pack-objects: refactor code into compute_layer_order() Add delta-islands.{c,h}
2018-09-17Merge branch 'jk/trailer-fixes'Libravatar Junio C Hamano1-2/+8
"git interpret-trailers" and its underlying machinery had a buggy code that attempted to ignore patch text after commit log message, which triggered in various codepaths that will always get the log message alone and never get such an input. * jk/trailer-fixes: append_signoff: use size_t for string offsets sequencer: ignore "---" divider when parsing trailers pretty, ref-filter: format %(trailers) with no_divider option interpret-trailers: allow suppressing "---" divider interpret-trailers: tighten check for "---" patch boundary trailer: pass process_trailer_opts to trailer_info_get() trailer: use size_t for iterating trailer list trailer: use size_t for string offsets
2018-09-17Merge branch 'tg/rerere'Libravatar Junio C Hamano1-0/+182
Fixes to "git rerere" corner cases, especially when conflict markers cannot be parsed in the file. * tg/rerere: rerere: recalculate conflict ID when unresolved conflict is committed rerere: teach rerere to handle nested conflicts rerere: return strbuf from handle path rerere: factor out handle_conflict function rerere: only return whether a path has conflicts or not rerere: fix crash with files rerere can't handle rerere: add documentation for conflict normalization rerere: mark strings for translation rerere: wrap paths in output in sq rerere: lowercase error messages rerere: unify error messages when read_cache fails
2018-09-17Merge branch 'ds/multi-pack-index'Libravatar Junio C Hamano4-0/+247
When there are too many packfiles in a repository (which is not recommended), looking up an object in these would require consulting many pack .idx files; a new mechanism to have a single file that consolidates all of these .idx files is introduced. * ds/multi-pack-index: (32 commits) pack-objects: consider packs in multi-pack-index midx: test a few commands that use get_all_packs treewide: use get_all_packs packfile: add all_packs list midx: fix bug that skips midx with alternates midx: stop reporting garbage midx: mark bad packed objects multi-pack-index: store local property multi-pack-index: provide more helpful usage info midx: clear midx on repack packfile: skip loading index if in multi-pack-index midx: prevent duplicate packfile loads midx: use midx in approximate_object_count midx: use existing midx when writing new one midx: use midx in abbreviation calculations midx: read objects from multi-pack-index config: create core.multiPackIndex setting midx: write object offsets midx: write object id fanout chunk midx: write object ids in a chunk ...
2018-09-17Merge branch 'jk/branch-l-1-repurpose'Libravatar Junio C Hamano1-7/+2
Updated plan to repurpose the "-l" option to "git branch". * jk/branch-l-1-repurpose: doc/git-branch: remove obsolete "-l" references branch: make "-l" a synonym for "--list"
2018-09-17Merge branch 'ts/doc-build-manpage-xsl-quietly'Libravatar Junio C Hamano1-1/+1
Build tweak. * ts/doc-build-manpage-xsl-quietly: Documentation/Makefile: make manpage-base-url.xsl generation quieter
2018-09-17Merge branch 'bp/checkout-new-branch-optim'Libravatar Junio C Hamano1-0/+8
"git checkout -b newbranch [HEAD]" should not have to do as much as checking out a commit different from HEAD. An attempt is made to optimize this special case. * bp/checkout-new-branch-optim: checkout: optimize "git checkout -b <new_branch>"
2018-09-17Revert "doc/Makefile: drop doc-diff worktree and temporary files on "make ↵Libravatar Junio C Hamano1-1/+0
clean"" This reverts commit 6f924265a0bf6efa677e9a684cebdde958e5ba06, which started to require that we have an executable git available in order to say "make clean", which gives us a chicken-and-egg problem. Having to have Git installed, or be in a repository, in order to be able to run an optional "doc-diff" tool is fine. Requiring either in order to run "make clean" is a different story. Reported by Jonathan Nieder <jrnieder@gmail.com>.
2018-09-10config: document value 2 for protocol.versionLibravatar Brandon Williams1-0/+2
Update the config documentation to note the value `2` as an acceptable value for the protocol.version config. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Josh Steadmon <steadmon@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-10Git 2.19Libravatar Junio C Hamano1-8/+0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-05doc-diff: force worktree addLibravatar Jeff King1-1/+1
We avoid re-creating our temporary worktree if it's already there. But we may run into a situation where the worktree has been deleted, but an entry still exists in $GIT_DIR/worktrees. Older versions of git-worktree would annoyingly create a series of duplicate entries. Recent versions now detect and prevent this, allowing you to override with "-f". Since we know that the worktree in question was just our temporary workspace, it's safe for us to always pass "-f". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-04Git 2.19-rc2Libravatar Junio C Hamano1-0/+23
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-04Documentation/git.txt: clarify that GIT_TRACE=/path appendsLibravatar SZEDER Gábor1-2/+2
The current wording of the description of GIT_TRACE=/path/to/file ("... will try to write the trace messages into it") might be misunderstood as "overwriting"; at least I interpreted it that way on a cursory first read. State it more explicitly that the trace messages are appended. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31fetch: stop clobbering existing tags without --forceLibravatar Ævar Arnfjörð Bjarmason1-4/+11
Change "fetch" to treat "+" in refspecs (aka --force) to mean we should clobber a local tag of the same name. This changes the long-standing behavior of "fetch" added in 853a3697dc ("[PATCH] Multi-head fetch.", 2005-08-20). Before this change, all tag fetches effectively had --force enabled. See the git-fetch-script code in fast_forward_local() with the comment: > Tags need not be pointing at commits so there is no way to > guarantee "fast-forward" anyway. That commit and the rest of the history of "fetch" shows that the "+" (--force) part of refpecs was only conceived for branch updates, while tags have accepted any changes from upstream unconditionally and clobbered the local tag object. Changing this behavior has been discussed as early as 2011[1]. The current behavior doesn't make sense to me, it easily results in local tags accidentally being clobbered. We could namespace our tags per-remote and not locally populate refs/tags/*, but as with my 97716d217c ("fetch: add a --prune-tags option and fetch.pruneTags config", 2018-02-09) it's easier to work around the current implementation than to fix the root cause. So this change implements suggestion #1 from Jeff's 2011 E-Mail[1], "fetch" now only clobbers the tag if either "+" is provided as part of the refspec, or if "--force" is provided on the command-line. This also makes it nicely symmetrical with how "tag" itself works when creating tags. I.e. we refuse to clobber any existing tags unless "--force" is supplied. Now we can refuse all such clobbering, whether it would happen by clobbering a local tag with "tag", or by fetching it from the remote with "fetch". Ref updates outside refs/{tags,heads/* are still still not symmetrical with how "git push" works, as discussed in the recently changed pull-fetch-param.txt documentation. This change brings the two divergent behaviors more into line with one another. I don't think there's any reason "fetch" couldn't fully converge with the behavior used by "push", but that's a topic for another change. One of the tests added in 31b808a032 ("clone --single: limit the fetch refspec to fetched branch", 2012-09-20) is being changed to use --force where a clone would clobber a tag. This changes nothing about the existing behavior of the test. 1. https://public-inbox.org/git/20111123221658.GA22313@sigill.intra.peff.net/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31fetch: document local ref updates with/without --forceLibravatar Ævar Arnfjörð Bjarmason2-10/+37
Refer to the new git-push(1) documentation about when ref updates are and aren't allowed with and without --force, noting how "git-fetch" differs from the behavior of "git-push". Perhaps it would be better to split this all out into a new gitrefspecs(7) man page, or present this information using tables. In lieu of that, this is accurate, and fixes a big omission in the existing refspec docs. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31push doc: correct lies about how push refspecs workLibravatar Ævar Arnfjörð Bjarmason2-11/+48
There's complex rules governing whether a push is allowed to take place depending on whether we're pushing to refs/heads/*, refs/tags/* or refs/not-that/*. See is_branch() in refs.c, and the various assertions in refs/files-backend.c. (e.g. "trying to write non-commit object %s to branch '%s'"). This documentation has never been quite correct, but went downhill after dbfeddb12e ("push: require force for refs under refs/tags/", 2012-11-29) when we started claiming that <dst> couldn't be a tag object, which is incorrect. After some of the logic in that patch was changed in 256b9d70a4 ("push: fix "refs/tags/ hierarchy cannot be updated without --force"", 2013-01-16) the docs weren't updated, and we've had some version of documentation that confused whether <src> was a tag or not with whether <dst> would accept either an annotated tag object or the commit it points to. This makes the intro somewhat more verbose & complex, perhaps we should have a shorter description here and split the full complexity into a dedicated section. Very few users will find themselves needing to e.g. push blobs or trees to refs/custom-namespace/* (or blobs or trees at all), and that could be covered separately as an advanced topic. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31push doc: move mention of "tag <tag>" later in the proseLibravatar Ævar Arnfjörð Bjarmason1-2/+2
This change will be followed-up with a subsequent change where I'll change both sides of this mention of "tag <tag>" to be something that's best read without interruption. To make that change smaller, let's move this mention of "tag <tag>" to the end of the "<refspec>..." section, it's now somewhere in the middle. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31push doc: remove confusing mention of remote mergerLibravatar Ævar Arnfjörð Bjarmason1-2/+1
Saying that "git push <remote> <src>:<dst>" won't push a merger of <src> and <dst> to <dst> is clear from the rest of the context here, so mentioning it is redundant, furthermore the mention of "EXAMPLES below" isn't specific or useful. This phrase was originally added in 149f6ddfb3 ("Docs: Expand explanation of the use of + in git push refspecs.", 2009-02-19), as can be seen in that change the point of the example being cited was to show that force pushing can leave unreferenced commits on the remote. It's enough that we explain that in its own section, it doesn't need to be mentioned here. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31doc/Makefile: drop doc-diff worktree and temporary files on "make clean"Libravatar Eric Sunshine1-0/+1
doc-diff creates a temporary working tree (git-worktree) and generates a bunch of temporary files which it does not remove since they act as a cache to speed up subsequent runs. Although doc-diff's working tree and generated files are not strictly build products of the Makefile (which, itself, never runs doc-diff), as a convenience, update "make clean" to clean up doc-diff's working tree and generated files along with other development detritus normally removed by "make clean". Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31doc-diff: add --clean mode to remove temporary working gunkLibravatar Eric Sunshine1-3/+16
As part of its operation, doc-diff creates a bunch of temporary working files and holds onto them in order to speed up subsequent invocations. These files are never deleted. Moreover, it creates a temporary working tree (via git-wortkree) which likewise never gets removed. Without knowing the implementation details of the tool, a user may not know how to clean up manually afterward. Worse, the user may find it surprising and alarming to discover a working tree which s/he did not create explicitly. To address these issues, add a --clean mode which removes the temporary working tree and deletes all generated files. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-31doc-diff: fix non-portable 'man' invocationLibravatar Eric Sunshine1-1/+1
doc-diff invokes 'man' with the -l option to force "local" mode, however, neither MacOS nor FreeBSD recognize this option. On those platforms, if the argument to 'man' contains a slash, it is automatically interpreted as a file specification, so a "local"-like mode is not needed. And, it turns out, 'man' which does support -l falls back to enabling -l automatically if it can't otherwise find a manual entry corresponding to the argument. Since doc-diff always passes an absolute path of the nroff source file to 'man', the -l option kicks in anyhow, despite not being specified explicitly. Therefore, make the invocation portable to the various platforms by simply dropping -l. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30doc/git-branch: remove obsolete "-l" referencesLibravatar Jeff King1-5/+1
The previous commit switched "-l" to meaning "--list", but a few vestiges of its prior meaning as "--create-reflog" remained: - the synopsis mentioned "-l" when creating a new branch; we can drop this entirely, as it has been the default for years - the --list command mentions the unfortunate "-l" confusion, but we've now fixed that Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30doc-diff: always use oids inside worktreeLibravatar Jeff King1-4/+4
The doc-diff script immediately resolves its two endpoints to actual object ids, so that we can reuse cached results even if they appear under a different name. But we still use the original name the user fed us when running "git checkout" in our temporary worktree. This can lead to confusing results: - the namespace inside the worktree is different than the one outside. In particular, "./doc-diff origin HEAD" will resolve HEAD inside the worktree, whose detached HEAD will be pointing at origin! As a result, such a diff would always be empty. - worse, we will store this result under the oid we got by resolving HEAD in the main worktree, thus polluting our cache - we didn't pass --detach, which meant that using a branch name would cause us to actually check out that branch, making it unavailable to other worktrees. We can solve this by feeding the already-resolved object id to git-checkout. That naturally forces a detached HEAD, but just to make clear our expectation, let's explicitly pass --detach. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30worktree: teach 'remove' to override lock when --force given twiceLibravatar Eric Sunshine1-0/+1
For consistency with "add -f -f" and "move -f -f" which override the lock on a worktree, allow "remove -f -f" to do so, as well, as a convenience. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30worktree: teach 'move' to override lock when --force given twiceLibravatar Eric Sunshine1-0/+3
For consistency with "add -f -f", which allows a missing but locked worktree path to be re-used, allow "move -f -f" to override a lock, as well, as a convenience. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-30worktree: teach 'add' to respect --force for registered but missing pathLibravatar Eric Sunshine1-2/+6
For safety, "git worktree add <path>" will refuse to add a new worktree at <path> if <path> is already associated with a worktree entry, even if <path> is missing (for instance, has been deleted or resides on non-mounted removable media or network share). The typical way to re-create a worktree at <path> in such a situation is either to prune all "broken" entries ("git worktree prune") or to selectively remove the worktree entry manually ("git worktree remove <path>"). However, neither of these approaches ("prune" nor "remove") is especially convenient, and they may be unsuitable for scripting when a tool merely wants to re-use a worktree if it exists or create it from scratch if it doesn't (much as a tool might use "mkdir -p" to re-use or create a directory). Therefore, teach 'add' to respect --force as a convenient way to re-use a path already associated with a worktree entry if the path is non-existent. For a locked worktree, require --force to be specified twice. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29Documentation/Makefile: make manpage-base-url.xsl generation quieterLibravatar Tim Schumacher1-1/+1
The exact sed command to generate manpage-base-url.xsl appears in the output, unlike the rules for other files that by default only show summary. Make the output for this rule similiar to all the other rules by printing a short status message instead of the whole command. Signed-off-by: Tim Schumacher <timschumi@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29rerere: add note about files with existing conflict markersLibravatar Thomas Gummerer1-0/+6
When a file contains lines that look like conflict markers, 'git rerere' may fail not be able to record a conflict resolution. Emphasize that in the man page, and mention a possible workaround for the issue. Suggested-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>
2018-08-29rerere: mention caveat about unmatched conflict markersLibravatar Thomas Gummerer1-0/+4
4af3220 ("rerere: teach rerere to handle nested conflicts", 2018-08-05) introduced slightly better behaviour if the user commits conflict markers and then gets another conflict in 'git rerere'. However this is just a heuristic to punt on such conflicts better, and doesn't deal with any unmatched conflict markers. Make that clearer in the documentation. Suggested-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>
2018-08-27Getting ready for -rc1Libravatar Junio C Hamano1-1/+34
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27Merge branch 'ds/commit-graph-fsck'Libravatar Junio C Hamano1-6/+11
Finishing touches to doc. * ds/commit-graph-fsck: config: fix commit-graph related config docs
2018-08-27Merge branch 'nd/complete-config-vars'Libravatar Junio C Hamano2-12/+12
"git help --config" (which is used in command line completion) missed the configuration variables not described in the main config.txt file but are described in another file that is included by it, which has been corrected. * nd/complete-config-vars: generate-cmdlist.sh: collect config from all config.txt files
2018-08-27Merge branch 'ep/worktree-quiet-option'Libravatar Junio C Hamano1-0/+4
"git worktree" command learned "--quiet" option to make it less verbose. * ep/worktree-quiet-option: worktree: add --quiet option
2018-08-27Merge branch 'sm/branch-sort-config'Libravatar Junio C Hamano2-2/+9
"git branch --list" learned to take the default sort order from the 'branch.sort' configuration variable, just like "git tag --list" pays attention to 'tag.sort'. * sm/branch-sort-config: branch: support configuring --sort via .gitconfig
2018-08-27Merge branch 'nd/config-core-checkstat-doc'Libravatar Junio C Hamano1-4/+14
The meaning of the possible values the "core.checkStat" configuration variable can take were not adequately documented, which has been fixed. * nd/config-core-checkstat-doc: config.txt: clarify core.checkStat
2018-08-23config: fix commit-graph related config docsLibravatar Derrick Stolee1-6/+11
The core.commitGraph config setting was accidentally removed from the config documentation. In that same patch, the config setting that writes a commit-graph during garbage collection was incorrectly written to the doc as "gc.commitGraph" instead of "gc.writeCommitGraph". Reported-by: Szeder Gábor <szeder.dev@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-23interpret-trailers: allow suppressing "---" dividerLibravatar Jeff King1-1/+6
Even with the newly-tightened "---" parser, it's still possible for a commit message to trigger a false positive if it contains something like "--- foo". If the caller knows that it has only a single commit message, it can now tell us with the "--no-divider" option, eliminating any false positives. If we were designing this from scratch, I'd probably make this the default. But we've advertised the "---" behavior in the documentation since interpret-trailers has existed. Since it's meant to be scripted, breaking that would be a bad idea. Note that the logic is in the underlying trailer.c code, which is used elsewhere. The default there will keep the current behavior, but many callers will benefit from setting this new option. That's left for future patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>