summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2018-08-20Merge branch 'hn/highlight-sideband-keywords'Libravatar Junio C Hamano1-0/+12
The sideband code learned to optionally paint selected keywords at the beginning of incoming lines on the receiving end. * hn/highlight-sideband-keywords: sideband: do not read beyond the end of input sideband: highlight keywords in remote sideband output
2018-08-20Merge branch 'sb/config-write-fix'Libravatar Junio C Hamano1-0/+21
Recent update to "git config" broke updating variable in a subsection, which has been corrected. * sb/config-write-fix: git-config: document accidental multi-line setting in deprecated syntax config: fix case sensitive subsection names on writing t1300: document current behavior of setting options
2018-08-20Merge branch 'jt/repack-promisor-packs'Libravatar Junio C Hamano1-0/+5
After a partial clone, repeated fetches from promisor remote would have accumulated many packfiles marked with .promisor bit without getting them coalesced into fewer packfiles, hurting performance. "git repack" now learned to repack them. * jt/repack-promisor-packs: repack: repack promisor objects if -a or -A is set repack: refactor setup of pack-objects cmd
2018-08-20Merge branch 'jh/partial-clone-doc'Libravatar Junio C Hamano2-104/+105
Doc updates. * jh/partial-clone-doc: partial-clone: render design doc using asciidoc
2018-08-20Merge branch 'js/range-diff'Libravatar Junio C Hamano2-2/+256
"git tbdiff" that lets us compare individual patches in two iterations of a topic has been rewritten and made into a built-in command. * js/range-diff: (21 commits) range-diff: use dim/bold cues to improve dual color mode range-diff: make --dual-color the default mode range-diff: left-pad patch numbers completion: support `git range-diff` range-diff: populate the man page range-diff --dual-color: skip white-space warnings range-diff: offer to dual-color the diffs diff: add an internal option to dual-color diffs of diffs color: add the meta color GIT_COLOR_REVERSE range-diff: use color for the commit pairs range-diff: add tests range-diff: do not show "function names" in hunk headers range-diff: adjust the output of the commit pairs range-diff: suppress the diff headers range-diff: indent the diffs just like tbdiff range-diff: right-trim commit messages range-diff: also show the diff between patches range-diff: improve the order of the shown commits range-diff: first rudimentary implementation Introduce `range-diff` to compare iterations of a topic branch ...
2018-08-20Merge branch 'jk/for-each-object-iteration'Libravatar Junio C Hamano1-0/+10
The API to iterate over all objects learned to optionally list objects in the order they appear in packfiles, which helps locality of access if the caller accesses these objects while as objects are enumerated. * jk/for-each-object-iteration: for_each_*_object: move declarations to object-store.h cat-file: use a single strbuf for all output cat-file: split batch "buf" into two variables cat-file: use oidset check-and-insert cat-file: support "unordered" output for --batch-all-objects cat-file: rename batch_{loose,packed}_object callbacks t1006: test cat-file --batch-all-objects with duplicates for_each_packed_object: support iterating in pack-order for_each_*_object: give more comprehensive docstrings for_each_*_object: take flag arguments as enum for_each_*_object: store flag definitions in a single location
2018-08-20Merge branch 'ab/fetch-tags-noclobber'Libravatar Junio C Hamano1-1/+1
Test and doc clean-ups. * ab/fetch-tags-noclobber: pull doc: fix a long-standing grammar error fetch tests: correct a comment "remove it" -> "remove them" push tests: assert re-pushing annotated tags push tests: add more testing for forced tag pushing push tests: fix logic error in "push" test assertion push tests: remove redundant 'git push' invocation fetch tests: change "Tag" test tag to "testTag"
2018-08-20Merge branch 'jc/update-index-doc'Libravatar Junio C Hamano1-9/+6
Doc update. * jc/update-index-doc: update-index: there no longer is `apply --index-info`
2018-08-20Merge branch 'en/update-index-doc'Libravatar Junio C Hamano1-2/+2
Doc update. * en/update-index-doc: git-update-index.txt: reword possibly confusing example
2018-08-20Merge branch 'ab/newhash-is-sha256'Libravatar Junio C Hamano1-98/+104
Documentation update. * ab/newhash-is-sha256: doc hash-function-transition: pick SHA-256 as NewHash doc hash-function-transition: note the lack of a changelog
2018-08-17Seventh batch for 2.19 cycleLibravatar Junio C Hamano1-0/+64
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-17Merge branch 'jk/diff-rendered-docs'Libravatar Junio C Hamano2-0/+110
The end result of documentation update has been made to be inspected more easily to help developers. * jk/diff-rendered-docs: add a script to diff rendered documentation
2018-08-17Merge branch 'nd/config-blame-sort'Libravatar Junio C Hamano1-34/+34
Doc fix. * nd/config-blame-sort: config.txt: reorder blame stuff to keep config keys sorted
2018-08-17Merge branch 'ab/fetch-nego'Libravatar Junio C Hamano2-1/+7
Update to a few other topics around 'git fetch'. * ab/fetch-nego: fetch doc: cross-link two new negotiation options negotiator: unknown fetch.negotiationAlgorithm should error out
2018-08-17Merge branch 'ab/fsck-transfer-updates'Libravatar Junio C Hamano1-35/+103
The test performed at the receiving end of "git push" to prevent bad objects from entering repository can be customized via receive.fsck.* configuration variables; we now have gained a counterpart to do the same on the "git fetch" side, with fetch.fsck.* configuration variables. * ab/fsck-transfer-updates: fsck: test and document unknown fsck.<msg-id> values fsck: add stress tests for fsck.skipList fsck: test & document {fetch,receive}.fsck.* config fallback fetch: implement fetch.fsck.* transfer.fsckObjects tests: untangle confusing setup config doc: elaborate on fetch.fsckObjects security config doc: elaborate on what transfer.fsckObjects does config doc: unify the description of fsck.* and receive.fsck.* config doc: don't describe *.fetchObjects twice receive.fsck.<msg-id> tests: remove dead code
2018-08-15Sixth batch for 2.19 cycleLibravatar Junio C Hamano1-0/+77
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-15Merge branch 'ms/http-proto-doc'Libravatar Junio C Hamano1-2/+2
Doc fix. * ms/http-proto-doc: doc: fix want-capability separator
2018-08-15Merge branch 'cb/p4-pre-submit-hook'Libravatar Junio C Hamano2-0/+15
"git p4 submit" learns to ask its own pre-submit hook if it should continue with submitting. * cb/p4-pre-submit-hook: git-p4: add the `p4-pre-submit` hook
2018-08-15Merge branch 'hs/gpgsm'Libravatar Junio C Hamano1-0/+10
Teach "git tag -s" etc. a few configuration variables (gpg.format that can be set to "openpgp" or "x509", and gpg.<format>.program that is used to specify what program to use to deal with the format) to allow x.509 certs with CMS via "gpgsm" to be used instead of openpgp via "gnupg". * hs/gpgsm: gpg-interface t: extend the existing GPG tests with GPGSM gpg-interface: introduce new signature format "x509" using gpgsm gpg-interface: introduce new config to select per gpg format program gpg-interface: do not hardcode the key string len anymore gpg-interface: introduce an abstraction for multiple gpg formats t/t7510: check the validation of the new config gpg.format gpg-interface: add new config to select how to sign a commit
2018-08-15Merge branch 'jk/core-use-replace-refs'Libravatar Junio C Hamano1-0/+5
A new configuration variable core.usereplacerefs has been added, primarily to help server installations that want to ignore the replace mechanism altogether. * jk/core-use-replace-refs: add core.usereplacerefs config option check_replace_refs: rename to read_replace_refs check_replace_refs: fix outdated comment
2018-08-15Merge branch 'es/diff-color-moved-fix'Libravatar Junio C Hamano1-1/+2
One of the "diff --color-moved" mode "dimmed_zebra" that was named in an unusual way has been deprecated and replaced by "dimmed-zebra". * es/diff-color-moved-fix: diff: --color-moved: rename "dimmed_zebra" to "dimmed-zebra"
2018-08-15Merge branch 'bw/protocol-v2'Libravatar Junio C Hamano1-1/+2
Doc update. * bw/protocol-v2: pack-protocol: mention and point to docs for protocol v2
2018-08-15Merge branch 'sb/trailers-docfix'Libravatar Junio C Hamano1-3/+6
Doc update. * sb/trailers-docfix: Documentation/git-interpret-trailers: explain possible values
2018-08-15Merge branch 'jk/ui-color-always-to-auto'Libravatar Junio C Hamano2-2/+2
Doc formatting fix. * jk/ui-color-always-to-auto: Documentation: fix --color option formatting
2018-08-15partial-clone: render design doc using asciidocLibravatar Jonathan Nieder2-104/+105
Rendered documentation can be easier to read than raw text because headings and emphasized phrases stand out. Add the missing markup and Makefile rule required to render this design document using asciidoc. Tested by running make -C Documentation technical/partial-clone.html and viewing the output in a browser. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13cat-file: support "unordered" output for --batch-all-objectsLibravatar Jeff King1-0/+10
If you're going to access the contents of every object in a packfile, it's generally much more efficient to do so in pack order, rather than in hash order. That increases the locality of access within the packfile, which in turn is friendlier to the delta base cache, since the packfile puts related deltas next to each other. By contrast, hash order is effectively random, since the sha1 has no discernible relationship to the content. This patch introduces an "--unordered" option to cat-file which iterates over packs in pack-order under the hood. You can see the results when dumping all of the file content: $ time ./git cat-file --batch-all-objects --buffer --batch | wc -c 6883195596 real 0m44.491s user 0m42.902s sys 0m5.230s $ time ./git cat-file --unordered \ --batch-all-objects --buffer --batch | wc -c 6883195596 real 0m6.075s user 0m4.774s sys 0m3.548s Same output, different order, way faster. The same speed-up applies even if you end up accessing the object content in a different process, like: git cat-file --batch-all-objects --buffer --batch-check | grep blob | git cat-file --batch='%(objectname) %(rest)' | wc -c Adding "--unordered" to the first command drops the runtime in git.git from 24s to 3.5s. Side note: there are actually further speedups available for doing it all in-process now. Since we are outputting the object content during the actual pack iteration, we know where to find the object and could skip the extra lookup done by oid_object_info(). This patch stops short of that optimization since the underlying API isn't ready for us to make those sorts of direct requests. So if --unordered is so much better, why not make it the default? Two reasons: 1. We've promised in the documentation that --batch-all-objects outputs in hash order. Since cat-file is plumbing, people may be relying on that default, and we can't change it. 2. It's actually _slower_ for some cases. We have to compute the pack revindex to walk in pack order. And our de-duplication step uses an oidset, rather than a sort-and-dedup, which can end up being more expensive. If we're just accessing the type and size of each object, for example, like: git cat-file --batch-all-objects --buffer --batch-check my best-of-five warm cache timings go from 900ms to 1100ms using --unordered. Though it's possible in a cold-cache or under memory pressure that we could do better, since we'd have better locality within the packfile. And one final question: why is it "--unordered" and not "--pack-order"? The answer is again two-fold: 1. "pack order" isn't a well-defined thing across the whole set of objects. We're hitting loose objects, as well as objects in multiple packs, and the only ordering we're promising is _within_ a single pack. The rest is apparently random. 2. The point here is optimization. So we don't want to promise any particular ordering, but only to say that we will choose an ordering which is likely to be efficient for accessing the object content. That leaves the door open for further changes in the future without having to add another compatibility option. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13pull doc: fix a long-standing grammar errorLibravatar Ævar Arnfjörð Bjarmason1-1/+1
It should be "is not an empty string" not "is not empty string". This fixes wording originally introduced in ab9b31386b ("Documentation: multi-head fetch.", 2005-08-24). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13range-diff: use dim/bold cues to improve dual color modeLibravatar Johannes Schindelin2-6/+17
It *is* a confusing thing to look at a diff of diffs. All too easy is it to mix up whether the -/+ markers refer to the "inner" or the "outer" diff, i.e. whether a `+` indicates that a line was added by either the old or the new diff (or both), or whether the new diff does something different than the old diff. To make things easier to process for normal developers, we introduced the dual color mode which colors the lines according to the commit diff, i.e. lines that are added by a commit (whether old, new, or both) are colored in green. In non-dual color mode, the lines would be colored according to the outer diff: if the old commit added a line, it would be colored red (because that line addition is only present in the first commit range that was specified on the command-line, i.e. the "old" commit, but not in the second commit range, i.e. the "new" commit). However, this dual color mode is still not making things clear enough, as we are looking at two levels of diffs, and we still only pick a color according to *one* of them (the outer diff marker is colored differently, of course, but in particular with deep indentation, it is easy to lose track of that outer diff marker's background color). Therefore, let's add another dimension to the mix. Still use green/red/normal according to the commit diffs, but now also dim the lines that were only in the old commit, and use bold face for the lines that are only in the new commit. That way, it is much easier not to lose track of, say, when we are looking at a line that was added in the previous iteration of a patch series but the new iteration adds a slightly different version: the obsolete change will be dimmed, the current version of the patch will be bold. At least this developer has a much easier time reading the range-diffs that way. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13range-diff: make --dual-color the default modeLibravatar Johannes Schindelin1-14/+18
After using this command extensively for the last two months, this developer came to the conclusion that even if the dual color mode still leaves a lot of room for confusion about what was actually changed, the non-dual color mode is substantially worse in that regard. Therefore, we really want to make the dual color mode the default. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13range-diff: populate the man pageLibravatar Johannes Schindelin1-0/+229
The bulk of this patch consists of a heavily butchered version of tbdiff's README written by Thomas Rast and Thomas Gummerer, lifted from https://github.com/trast/tbdiff. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13Introduce `range-diff` to compare iterations of a topic branchLibravatar Johannes Schindelin1-0/+10
This command does not do a whole lot so far, apart from showing a usage that is oddly similar to that of `git tbdiff`. And for a good reason: the next commits will turn `range-branch` into a full-blown replacement for `tbdiff`. At this point, we ignore tbdiff's color options, as they will all be implemented later using diff_options. Since f318d739159 (generate-cmds.sh: export all commands to command-list.h, 2018-05-10), every new command *requires* a man page to build right away, so let's also add a blank man page, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-09repack: repack promisor objects if -a or -A is setLibravatar Jonathan Tan1-0/+5
Currently, repack does not touch promisor packfiles at all, potentially causing the performance of repositories that have many such packfiles to drop. Therefore, repack all promisor objects if invoked with -a or -A. This is done by an additional invocation of pack-objects on all promisor objects individually given, which takes care of deduplication and allows the resulting packfiles to respect flags such as --max-pack-size. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-08sideband: highlight keywords in remote sideband outputLibravatar Han-Wen Nienhuys1-0/+12
The colorization is controlled with the config setting "color.remote". Supported keywords are "error", "warning", "hint" and "success". They are highlighted if they appear at the start of the line, which is common in error messages, eg. ERROR: commit is missing Change-Id The Git push process itself prints lots of non-actionable messages (eg. bandwidth statistics, object counters for different phases of the process). This obscures actionable error messages that servers may send back. Highlighting keywords in the sideband draws more attention to those messages. The background for this change is that Gerrit does server-side processing to create or update code reviews, and actionable error messages (eg. missing Change-Id) must be communicated back to the user during the push. User research has shown that new users have trouble seeing these messages. The highlighting is done on the client rather than server side, so servers don't have to grow capabilities to understand terminal escape codes and terminal state. It also consistent with the current state where Git is control of the local display (eg. prefixing messages with "remote: "). The highlighting can be configured using color.remote.<KEYWORD> configuration settings. Since the keys are matched case insensitively, we match the keywords case insensitively too. Finally, this solution is backwards compatible: many servers already prefix their messages with "error", and they will benefit from this change without requiring a server update. By contrast, a server-side solution would likely require plumbing the TERM variable through the git protocol, so it would require changes to both server and client. Helped-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-08update-index: there no longer is `apply --index-info`Libravatar Junio C Hamano1-9/+6
Back when we removed `git apply --index-info` in 2007, we forgot to adjust the documentation for update-index that reads its output. Let's reorder the description of three formats to present the other two formats that are still generated by git commands before this format, and stop mentioning `git apply --index-info`. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-08git-update-index.txt: reword possibly confusing exampleLibravatar Elijah Newren1-2/+2
The following phrase could be interpreted multiple ways: "To pretend you have a file with mode and sha1 at path" In particular, I can think of two: 1. Pretend we have some new file, which happens to have a given mode and sha1 2. Pretend one of the files we are already tracking has a different mode and sha1 than what it really does I think people could easily assume either case while reading, but the example command provided doesn't actually handle the first case, which caused some minor frustration to at least one user. Modify the example command so that it correctly handles both cases, and re-order the wording in a way that makes it more likely folks will assume the first interpretation. I believe the new example shouldn't pose any obstacles to those wanting the second interpretation (at worst, they pass an unnecessary extra flag). Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-08git-config: document accidental multi-line setting in deprecated syntaxLibravatar Stefan Beller1-0/+21
The bug was noticed when writing the previous patch; a fix for this bug is not easy though: If we choose to ignore the case of the subsection (and revert most of the code of the previous patch, just keeping s/strncasecmp/strcmp/), then we'd introduce new sections using the new syntax, such that -------- [section.subsection] key = value1 -------- git config section.Subsection.key value2 would result in -------- [section.subsection] key = value1 [section.Subsection] key = value2 -------- which is even more confusing. A proper fix would replace the first occurrence of 'key'. As the syntax is deprecated, let's prefer to not spend time on fixing the behavior and just document it instead. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-07doc hash-function-transition: pick SHA-256 as NewHashLibravatar Jonathan Nieder1-98/+98
From a security perspective, it seems that SHA-256, BLAKE2, SHA3-256, K12, and so on are all believed to have similar security properties. All are good options from a security point of view. SHA-256 has a number of advantages: * It has been around for a while, is widely used, and is supported by just about every single crypto library (OpenSSL, mbedTLS, CryptoNG, SecureTransport, etc). * When you compare against SHA1DC, most vectorized SHA-256 implementations are indeed faster, even without acceleration. * If we're doing signatures with OpenPGP (or even, I suppose, CMS), we're going to be using SHA-2, so it doesn't make sense to have our security depend on two separate algorithms when either one of them alone could break the security when we could just depend on one. So SHA-256 it is. Update the hash-function-transition design doc to say so. After this patch, there are no remaining instances of the string "NewHash", except for an unrelated use from 2008 as a variable name in t/t9700/test.pl. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Acked-by: Dan Shumow <danshu@microsoft.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-06add a script to diff rendered documentationLibravatar Jeff King2-0/+110
After making a change to the documentation, it's easy to forget to check the rendered version to make sure it was formatted as you intended. And simply doing a diff between the two built versions is less trivial than you might hope: - diffing the roff or html output isn't particularly readable; what we really care about is what the end user will see - you have to tweak a few build variables to avoid spurious differences (e.g., version numbers, build times) Let's provide a script that builds and installs the manpages for two commits, renders the results using "man", and diffs the result. Since this is time-consuming, we'll also do our best to avoid repeated work, keeping intermediate results between runs. Some of this could probably be made a little less ugly if we built support into Documentation/Makefile. But by relying only on "make install-man" working, this script should work for generating a diff between any two versions, whether they include this script or not. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-06config.txt: reorder blame stuff to keep config keys sortedLibravatar Nguyễn Thái Ngọc Duy1-34/+34
The color group in config.txt is actually sorted but changes in sb/blame-color broke this. Reorder color.blame.* and move blame.coloring back to the rest of blame.* (and reorder that group too while we're there) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-02Fifth batch for 2.19 cycleLibravatar Junio C Hamano1-0/+107
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-02Merge branch 'jt/fetch-negotiator-skipping'Libravatar Junio C Hamano1-0/+9
Add a server-side knob to skip commits in exponential/fibbonacci stride in an attempt to cover wider swath of history with a smaller number of iterations, potentially accepting a larger packfile transfer, instead of going back one commit a time during common ancestor discovery during the "git fetch" transaction. * jt/fetch-negotiator-skipping: negotiator/skipping: skip commits during fetch
2018-08-02Merge branch 'en/dirty-merge-fixes'Libravatar Junio C Hamano1-3/+3
The recursive merge strategy did not properly ensure there was no change between HEAD and the index before performing its operation, which has been corrected. * en/dirty-merge-fixes: merge: fix misleading pre-merge check documentation merge-recursive: enforce rule that index matches head before merging t6044: add more testcases with staged changes before a merge is invoked merge-recursive: fix assumption that head tree being merged is HEAD merge-recursive: make sure when we say we abort that we actually abort t6044: add a testcase for index matching head, when head doesn't match HEAD t6044: verify that merges expected to abort actually abort index_has_changes(): avoid assuming operating on the_index read-cache.c: move index_has_changes() from merge.c
2018-08-02Merge branch 'js/rebase-merge-octopus'Libravatar Junio C Hamano2-4/+13
"git rebase --rebase-merges" mode now handles octopus merges as well. * js/rebase-merge-octopus: rebase --rebase-merges: adjust man page for octopus support rebase --rebase-merges: add support for octopus merges merge: allow reading the merge commit message from a file
2018-08-02Merge branch 'tb/grep-only-matching'Libravatar Junio C Hamano1-1/+6
"git grep" learned the "--only-matching" option. * tb/grep-only-matching: grep.c: teach 'git grep --only-matching' grep.c: extract show_line_header()
2018-08-02Merge branch 'jt/fetch-nego-tip'Libravatar Junio C Hamano1-0/+16
"git fetch" learned a new option "--negotiation-tip" to limit the set of commits it tells the other end as "have", to reduce wasted bandwidth and cycles, which would be helpful when the receiving repository has a lot of refs that have little to do with the history at the remote it is fetching from. * jt/fetch-nego-tip: fetch-pack: support negotiation tip whitelist
2018-08-02Merge branch 'ab/checkout-default-remote'Libravatar Junio C Hamano3-0/+44
"git checkout" and "git worktree add" learned to honor checkout.defaultRemote when auto-vivifying a local branch out of a remote tracking branch in a repository with multiple remotes that have tracking branches that share the same names. * ab/checkout-default-remote: checkout & worktree: introduce checkout.defaultRemote checkout: add advice for ambiguous "checkout <branch>" builtin/checkout.c: use "ret" variable for return checkout: pass the "num_matches" up to callers checkout.c: change "unique" member to "num_matches" checkout.c: introduce an *_INIT macro checkout.h: wrap the arguments to unique_tracking_name() checkout tests: index should be clean after dwim checkout
2018-08-02Merge branch 'sb/diff-color-move-more'Libravatar Junio C Hamano2-2/+36
"git diff --color-moved" feature has further been tweaked. * sb/diff-color-move-more: diff.c: offer config option to control ws handling in move detection diff.c: add white space mode to move detection that allows indent changes diff.c: factor advance_or_nullify out of mark_color_as_moved diff.c: decouple white space treatment from move detection algorithm diff.c: add a blocks mode for moved code detection diff.c: adjust hash function signature to match hashmap expectation diff.c: do not pass diff options as keydata to hashmap t4015: avoid git as a pipe input xdiff/xdiffi.c: remove unneeded function declarations xdiff/xdiff.h: remove unused flags
2018-08-02Merge branch 'ds/commit-graph-fsck'Libravatar Junio C Hamano5-27/+25
"git fsck" learns to make sure the optional commit-graph file is in a sane state. * ds/commit-graph-fsck: (23 commits) coccinelle: update commit.cocci commit-graph: update design document gc: automatically write commit-graph files commit-graph: add '--reachable' option commit-graph: use string-list API for input fsck: verify commit-graph commit-graph: verify contents match checksum commit-graph: test for corrupted octopus edge commit-graph: verify commit date commit-graph: verify generation number commit-graph: verify parent list commit-graph: verify root tree OIDs commit-graph: verify objects exist commit-graph: verify corrupt OID fanout and lookup commit-graph: verify required chunks are present commit-graph: verify catches corrupt signature commit-graph: add 'verify' subcommand commit-graph: load a root tree from specific graph commit: force commit to parse from object database commit-graph: parse commit from chosen graph ...
2018-08-01git-p4: add the `p4-pre-submit` hookLibravatar Chen Bin2-0/+15
The `p4-pre-submit` hook is executed before git-p4 submits code. If the hook exits with non-zero value, submit process not start. Signed-off-by: Chen Bin <chenbin.sh@gmail.com> Reviewed-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-01fetch doc: cross-link two new negotiation optionsLibravatar Ævar Arnfjörð Bjarmason2-0/+5
Users interested in the fetch.negotiationAlgorithm variable added in 42cc7485a2 ("negotiator/skipping: skip commits during fetch", 2018-07-16) are probably interested in the related --negotiation-tip option added in 3390e42adb ("fetch-pack: support negotiation tip whitelist", 2018-07-02). Change the documentation for those two to reference one another to point readers in the right direction. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>