summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2018-11-06Merge branch 'nd/completion-negation'Libravatar Junio C Hamano1-1/+1
The command line completion machinery (in contrib/) has been updated to allow the completion script to tweak the list of options that are reported by the parse-options machinery correctly. * nd/completion-negation: completion: fix __gitcomp_builtin no longer consider extra options
2018-10-30Merge branch 'dl/mergetool-gui-option'Libravatar Junio C Hamano1-1/+1
"git mergetool" learned to take the "--[no-]gui" option, just like "git difftool" does. * dl/mergetool-gui-option: doc: document diff/merge.guitool config keys completion: support `git mergetool --[no-]gui` mergetool: accept -g/--[no-]gui as arguments
2018-10-30Merge branch 'js/mingw-load-sys-dll'Libravatar Junio C Hamano1-1/+2
The way DLLs are loaded on the Windows port has been improved. * js/mingw-load-sys-dll: mingw: load system libraries the recommended way
2018-10-30Merge branch 'jc/cocci-preincr'Libravatar Junio C Hamano1-0/+5
Code cleanup. * jc/cocci-preincr: fsck: s/++i > 1/i++/ cocci: simplify "if (++u > 1)" to "if (u++)"
2018-10-30Merge branch 'bc/hash-transition-part-15'Libravatar Junio C Hamano1-54/+63
More codepaths are moving away from hardcoded hash sizes. * bc/hash-transition-part-15: rerere: convert to use the_hash_algo submodule: make zero-oid comparison hash function agnostic apply: rename new_sha1_prefix and old_sha1_prefix apply: replace hard-coded constants tag: express constant in terms of the_hash_algo transport: use parse_oid_hex instead of a constant upload-pack: express constants in terms of the_hash_algo refs/packed-backend: express constants using the_hash_algo packfile: express constants in terms of the_hash_algo pack-revindex: express constants in terms of the_hash_algo builtin/fetch-pack: remove constants with parse_oid_hex builtin/mktree: remove hard-coded constant builtin/repack: replace hard-coded constants pack-bitmap-write: use GIT_MAX_RAWSZ for allocation object_id.cocci: match only expressions of type 'struct object_id'
2018-10-30Merge branch 'ch/subtree-build'Libravatar Junio C Hamano1-0/+4
Build update for "git subtree" (in contrib/) documentation pages. * ch/subtree-build: Revert "subtree: make install targets depend on build targets" subtree: make install targets depend on build targets subtree: add build targets 'man' and 'html'
2018-10-26Merge branch 'du/cherry-is-plumbing'Libravatar Junio C Hamano1-11/+0
Doc update to mark "git cherry" as a plumbing command. * du/cherry-is-plumbing: doc: move git-cherry to plumbing
2018-10-26Merge branch 'ds/coverage-diff'Libravatar Junio C Hamano1-0/+108
The result of coverage test can be combined with "git blame" to check the test coverage of code introduced recently with a new 'coverage-diff' tool (in contrib/). * ds/coverage-diff: contrib: add coverage-diff script
2018-10-26Merge branch 'rs/subtree-fixes'Libravatar Junio C Hamano1-46/+83
Various subtree fixes. * rs/subtree-fixes: subtree: performance improvement for finding unexpected parent commits subtree: improve decision on merges kept in split subtree: use commits before rejoins for splits subtree: make --ignore-joins pay attention to adds subtree: refactor split of a commit into standalone method
2018-10-25completion: support `git mergetool --[no-]gui`Libravatar Denton Liu1-1/+1
Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Anmol Mago <anmolmago@gmail.com> Signed-off-by: Brian Ho <briankyho@gmail.com> Signed-off-by: David Lu <david.lu97@outlook.com> Signed-off-by: Ryan Wang <shirui.wang@hotmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-24mingw: load system libraries the recommended wayLibravatar Johannes Schindelin1-1/+2
When we access IPv6-related functions, we load the corresponding system library using the `LoadLibrary()` function, which is not the recommended way to load system libraries. In practice, it does not make a difference: the `ws2_32.dll` library containing the IPv6 functions is already loaded into memory, so LoadLibrary() simply reuses the already-loaded library. Still, recommended way is recommended way, so let's use that instead. While at it, also adjust the code in contrib/ that loads system libraries. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-24cocci: simplify "if (++u > 1)" to "if (u++)"Libravatar Junio C Hamano1-0/+5
It is more common to use post-increment than pre-increment when the side effect is the primary thing we want in our code and in C in general (unlike C++). Initializing a variable to 0, incrementing it every time we do something, and checking if we have already done that thing to guard the code to do that thing, is easier to understand when written if (u++) ; /* we've done that! */ else do_it(); /* just once. */ but if you try to use pre-increment, you end up with a less natural looking if (++u > 1) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-22completion: fix __gitcomp_builtin no longer consider extra optionsLibravatar Nguyễn Thái Ngọc Duy1-1/+1
__gitcomp_builtin() has the main completion list provided by git xxx --git-completion-helper but the caller can also add extra options that is not provided by --git-completion-helper. The only call site that does this is "git difftool" completion. This support is broken by b221b5ab9b (completion: collapse extra --no-.. options - 2018-06-06), which adds a special value "--" to mark that the rest of the options can be hidden by default. The commit forgets the fact that extra options are appended after "$(git xxx --git-completion-helper)", i.e. after this "--", and will be incorrectly hidden as well. Prepend the extra options before "$(git xxx --git-completion-helper)" to avoid this. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-19Merge branch 'nd/complete-fetch-multiple-args'Libravatar Junio C Hamano1-0/+1
Teach bash completion that "git fetch --multiple" only takes remote names as arguments and no refspecs. * nd/complete-fetch-multiple-args: completion: support "git fetch --multiple"
2018-10-18Revert "subtree: make install targets depend on build targets"Libravatar Junio C Hamano1-3/+3
This reverts commit 744f7c4c314dc0e7816ac05520e8358c8318187a. These targets do depend on the fact that each prereq is explicitly listed via their use of $^, which I failed to notice, and broke the build.
2018-10-16subtree: make install targets depend on build targetsLibravatar Christian Hesse1-3/+3
Now that we have build targets let the install targets depend on them. Also make the targets phony. Signed-off-by: Christian Hesse <mail@eworm.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-15object_id.cocci: match only expressions of type 'struct object_id'Libravatar SZEDER Gábor1-54/+63
Most of our semantic patches in 'contrib/coccinelle/object_id.cocci' turn calls of SHA1-specific functions into calls of their corresponding object_id counterparts, e.g. sha1_to_hex() to oid_to_hex(). These semantic patches look something like this: @@ expression E1; @@ - sha1_to_hex(E1.hash) + oid_to_hex(&E1) and match the access to the 'hash' field in any data type, not only in 'struct object_id', and, consquently, can produce wrong transformations. Case in point is the recent hash function transition patch "rerere: convert to use the_hash_algo" [1], which, among other things, renamed 'struct rerere_dir's 'sha1' field to 'hash', and then 'make coccicheck' started to suggest the following wrong transformations for 'rerere.c' [2]: - return sha1_to_hex(id->collection->hash); + return oid_to_hex(id->collection); and - DIR *dir = opendir(git_path("rr-cache/%s", sha1_to_hex(rr_dir->hash))); + DIR *dir = opendir(git_path("rr-cache/%s", oid_to_hex(rr_dir))); Avoid such wrong transformations by tightening semantic patches in 'object_id.cocci' to match only type of or pointers to 'struct object_id'. [1] https://public-inbox.org/git/20181008215701.779099-15-sandals@crustytoothpaste.net/ [2] https://travis-ci.org/git/git/jobs/440463476#L580 Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-12subtree: performance improvement for finding unexpected parent commitsLibravatar Roger Strain1-1/+1
After testing a previous patch at larger scale, a performance issue was detected when using git show to locate parent revisions, with a single run of the git show command taking 2 seconds or longer in a complex repo. When the command is required tens or hundreds of times in a run of the script, the additional wait time is unaccepatable. Replacing the command with git rev-parse resulted in significantly increased performance, with the command in question returning instantly. Signed-off-by: Roger Strain <rstrain@swri.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-12doc: move git-cherry to plumbingLibravatar Daniels Umanovskis1-11/+0
Also remove git-cherry from Bash completion because plumbing commands do not belong there. Signed-off-by: Daniels Umanovskis <daniels@umanovskis.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-10subtree: add build targets 'man' and 'html'Libravatar Christian Hesse1-0/+4
We have targets 'install-man' and 'install-html', let's add build targets as well. Signed-off-by: Christian Hesse <mail@eworm.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-10contrib: add coverage-diff scriptLibravatar Derrick Stolee1-0/+108
We have coverage targets in our Makefile for using gcov to display line coverage based on our test suite. The way I like to do it is to run: make coverage-test make coverage-report This leaves the repo in a state where every X.c file that was covered has an X.c.gcov file containing the coverage counts for every line, and "#####" at every uncovered line. There have been a few bugs in recent patches what would have been caught if the test suite covered those blocks (including a few of mine). I want to work towards a "sensible" amount of coverage on new topics. In my opinion, this means that any logic should be covered, but the 'die()' blocks covering very unlikely (or near-impossible) situations may not warrant coverage. It is important to not measure the coverage of the codebase by what old code is not covered. To help, I created the 'contrib/coverage-diff.sh' script. After creating the coverage statistics at a version (say, 'topic') you can then run contrib/coverage-diff.sh base topic to see the lines added between 'base' and 'topic' that are not covered by the test suite. The output uses 'git blame -s' format so you can find the commits responsible and view the line numbers for quick access to the context, but trims leading tabs in the file contents to reduce output width. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-07git-completion.bash: add completion for stash listLibravatar Steven Fernandez1-0/+3
Since stash list accepts git-log options, add the following useful options that make sense in the context of the `git stash list` command: --name-status --oneline --patch-with-stat Signed-off-by: Steven Fernandez <steve@lonetwin.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-07subtree: improve decision on merges kept in splitLibravatar Strain, Roger L1-2/+19
When multiple identical parents are detected for a commit being considered for copying, explicitly check whether one is the common merge base between the commits. If so, the other commit can be used as the identical parent; if not, a merge must be performed to maintain history. In some situations two parents of a merge commit may appear to both have identical subtree content with each other and the current commit. However, those parents can potentially come from different commit graphs. Previous behavior would simply select one of the identical parents to serve as the replacement for this commit, based on the order in which they were processed. New behavior compares the merge base between the commits to determine if a new merge commit is necessary to maintain history despite the identical content. Signed-off-by: Strain, Roger L <roger.strain@swri.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-07subtree: use commits before rejoins for splitsLibravatar Strain, Roger L1-6/+20
Adds recursive evaluation of parent commits which were not part of the initial commit list when performing a split. Split expects all relevant commits to be reachable from the target commit but not reachable from any previous rejoins. However, a branch could be based on a commit prior to a rejoin, then later merged back into the current code. In this case, a parent to the commit will not be present in the initial list of commits, trigging an "incorrect order" warning. Previous behavior was to consider that commit to have no parent, creating an original commit containing all subtree content. This commit is not present in an existing subtree commit graph, changing commit hashes and making pushing to a subtree repo impossible. New behavior will recursively check these unexpected parent commits to track them back to either an earlier rejoin, or a true original commit. The generated synthetic commits will properly match previously-generated commits, allowing successful pushing to a prior subtree repo. Signed-off-by: Strain, Roger L <roger.strain@swri.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-07subtree: make --ignore-joins pay attention to addsLibravatar Strain, Roger L1-7/+7
Changes the behavior of --ignore-joins to always consider a subtree add commit, and ignore only splits and squashes. The --ignore-joins option is documented to ignore prior --rejoin commits. However, it additionally ignored subtree add commits generated when a subtree was initially added to a repo. Due to the logic which determines whether a commit is a mainline commit or a subtree commit (namely, the presence or absence of content in the subtree prefix) this causes commits before the initial add to appear to be part of the subtree. An --ignore-joins split would therefore consider those commits part of the subtree history and include them at the beginning of the synthetic history, causing the resulting hashes to be incorrect for all later commits. Signed-off-by: Strain, Roger L <roger.strain@swri.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-07subtree: refactor split of a commit into standalone methodLibravatar Strain, Roger L1-36/+42
In a particularly complex repo, subtree split was not creating compatible splits for pushing back to a separate repo. Addressing one of the issues requires recursive handling of parent commits that were not initially considered by the algorithm. This commit makes no functional changes, but relocates the code to be called recursively into a new method to simply comparisons of later commits. Signed-off-by: Strain, Roger L <roger.strain@swri.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-21completion: support "git fetch --multiple"Libravatar Nguyễn Thái Ngọc Duy1-0/+1
When --multiple is given, the remaining arguments are remote names, not one remote followed by zero or more refspec. Detect this case, disable refspec completion, and pretend no remote is seen in order to complete multiple of them. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29convert "hashcmp() != 0" to "!hasheq()"Libravatar Jeff King1-0/+9
This rounds out the previous three patches, covering the inequality logic for the "hash" variant of the functions. As with the previous three, the accompanying code changes are the mechanical result of applying the coccinelle patch; see those patches for more discussion. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29convert "oidcmp() != 0" to "!oideq()"Libravatar Jeff King1-0/+6
This is the flip side of the previous two patches: checking for a non-zero oidcmp() can be more strictly expressed as inequality. Like those patches, we write "!= 0" in the coccinelle transformation, which covers by isomorphism the more common: if (oidcmp(E1, E2)) As with the previous two patches, this patch can be achieved almost entirely by running "make coccicheck"; the only differences are manual line-wrap fixes to match the original code. There is one thing to note for anybody replicating this, though: coccinelle 1.0.4 seems to miss the case in builtin/tag.c, even though it's basically the same as all the others. Running with 1.0.7 does catch this, so presumably it's just a coccinelle bug that was fixed in the interim. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29convert "hashcmp() == 0" to hasheq()Libravatar Jeff King1-0/+9
This is the partner patch to the previous one, but covering the "hash" variants instead of "oid". Note that our coccinelle rule is slightly more complex to avoid triggering the call in hasheq(). I didn't bother to add a new rule to convert: - hasheq(E1->hash, E2->hash) + oideq(E1, E2) Since these are new functions, there won't be any such existing callers. And since most of the code is already using oideq, we're not likely to introduce new ones. We might still see "!hashcmp(E1->hash, E2->hash)" from topics in flight. But because our new rule comes after the existing ones, that should first get converted to "!oidcmp(E1, E2)" and then to "oideq(E1, E2)". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29convert "oidcmp() == 0" to oideq()Libravatar Jeff King1-0/+6
Using the more restrictive oideq() should, in the long run, give the compiler more opportunities to optimize these callsites. For now, this conversion should be a complete noop with respect to the generated code. The result is also perhaps a little more readable, as it avoids the "zero is equal" idiom. Since it's so prevalent in C, I think seasoned programmers tend not to even notice it anymore, but it can sometimes make for awkward double negations (e.g., we can drop a few !!oidcmp() instances here). This patch was generated almost entirely by the included coccinelle patch. This mechanical conversion should be completely safe, because we check explicitly for cases where oidcmp() is compared to 0, which is what oideq() is doing under the hood. Note that we don't have to catch "!oidcmp()" separately; coccinelle's standard isomorphisms make sure the two are treated equivalently. I say "almost" because I did hand-edit the coccinelle output to fix up a few style violations (it mostly keeps the original formatting, but sometimes unwraps long lines). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-29coccinelle: use <...> for function exclusionLibravatar Jeff King2-12/+12
Sometimes we want to suppress a coccinelle transformation inside a particular function. For example, in finding conversions of hashcmp() to oidcmp(), we should not convert the call in oidcmp() itself, since that would cause infinite recursion. We write that like this: @@ identifier f != oidcmp; expression E1, E2; @@ f(...) {... - hashcmp(E1->hash, E2->hash) + oidcmp(E1, E2) ...} to match the interior of any function _except_ oidcmp(). Unfortunately, this doesn't catch all cases (e.g., the one in sequencer.c that this patch fixes). The problem, as explained by one of the Coccinelle developers in [1], is: For transformation, A ... B requires that B occur on every execution path starting with A, unless that execution path ends up in error handling code. (eg, if (...) { ... return; }). Here your A is the start of the function. So you need a call to hashcmp on every path through the function, which fails when you add ifs. [...] Another issue with A ... B is that by default A and B should not appear in the matched region. So your original rule matches only the case where every execution path contains exactly one call to hashcmp, not more than one. One way to solve this is to put the pattern inside an angle-bracket pattern like "<... P ...>", which allows zero or more matches of P. That works (and is what this patch does), but it has one drawback: it matches more than we care about, and Coccinelle uses extra CPU. Here are timings for "make coccicheck" before and after this patch: [before] real 1m27.122s user 7m34.451s sys 0m37.330s [after] real 2m18.040s user 10m58.310s sys 0m41.549s That's not ideal, but it's more important for this to be correct than to be fast. And coccicheck is already fairly slow (and people don't run it for every single patch). So it's an acceptable tradeoff. There _is_ a better way to do it, which is to record the position at which we find hashcmp(), and then check it against the forbidden function list. Like: @@ position p : script:python() { p[0].current_element != "oidcmp" }; expression E1,E2; @@ - hashcmp@p(E1->hash, E2->hash) + oidcmp(E1, E2) This is only a little slower than the current code, and does the right thing in all cases. Unfortunately, not all builds of Coccinelle include python support (including the ones in Debian). Requiring it may mean that fewer people can easily run the tool, which is worse than it simply being a little slower. We may want to revisit this decision in the future if: - builds with python become more common - we find more uses for python support that tip the cost-benefit analysis But for now this patch sticks with the angle-bracket solution, and converts all existing cocci patches. This fixes only one missed case in the current code, though it makes a much better difference for some new rules I'm adding (converting "!hashcmp()" to "hasheq()" misses over half the possible conversions using the old form). [1] https://public-inbox.org/git/alpine.DEB.2.21.1808240652370.2344@hadrien/ Helped-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-20Merge branch 'js/range-diff'Libravatar Junio C Hamano1-0/+14
"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-15Merge branch 'es/mw-to-git-chain-fix'Libravatar Junio C Hamano1-1/+1
Test fix. * es/mw-to-git-chain-fix: mw-to-git/t9360: fix broken &&-chain
2018-08-15Merge branch 'jn/subtree-test-fixes'Libravatar Junio C Hamano1-90/+31
Test fix. * jn/subtree-test-fixes: subtree test: simplify preparation of expected results subtree test: add missing && to &&-chain
2018-08-15Merge branch 'js/vscode'Libravatar Junio C Hamano3-0/+390
Add a script (in contrib/) to help users of VSCode work better with our codebase. * js/vscode: vscode: let cSpell work on commit messages, too vscode: add a dictionary for cSpell vscode: use 8-space tabs, no trailing ws, etc for Git's source code vscode: wrap commit messages at column 72 by default vscode: only overwrite C/C++ settings mingw: define WIN32 explicitly cache.h: extract enum declaration from inside a struct declaration vscode: hard-code a couple defines contrib: add a script to initialize VS Code configuration
2018-08-13range-diff: make --dual-color the default modeLibravatar Johannes Schindelin1-1/+1
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-13completion: support `git range-diff`Libravatar Johannes Schindelin1-0/+14
Tab completion of `git range-diff` is very convenient, especially given that the revision arguments to specify the commit ranges to compare are typically more complex than, say, what is normally passed to `git log`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-02Merge branch 'ds/commit-graph-fsck'Libravatar Junio C Hamano1-1/+1
"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-07-31mw-to-git/t9360: fix broken &&-chainLibravatar Eric Sunshine1-1/+1
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-30subtree test: simplify preparation of expected resultsLibravatar Jonathan Nieder1-89/+30
This mixture of quoting, pipes, and here-docs to produce expected results in shell variables is difficult to follow. Simplify by using simpler constructs that write output to files instead. Noticed because without this patch, t/chainlint is not able to understand the script in order to validate that its subshells use an unbroken &&-chain, causing "make -C contrib/subtree test" to fail with error: bug in the test script: broken &&-chain or run-away HERE-DOC: in t7900.21. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-30subtree test: add missing && to &&-chainLibravatar Jonathan Nieder1-1/+1
Detected using t/chainlint. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-30vscode: let cSpell work on commit messages, tooLibravatar Johannes Schindelin1-0/+2
By default, the cSpell extension ignores all files under .git/. That includes, unfortunately, COMMIT_EDITMSG, i.e. commit messages. However, spell checking is *quite* useful when writing commit messages... And since the user hardly ever opens any file inside .git (apart from commit messages, the config, and sometimes interactive rebase's todo lists), there is really not much harm in *not* ignoring .git/. The default also ignores `node_modules/`, but that does not apply to Git, so let's skip ignoring that, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-30vscode: add a dictionary for cSpellLibravatar Johannes Schindelin1-1/+168
The quite useful cSpell extension allows VS Code to have "squiggly" lines under spelling mistakes. By default, this would add too much clutter, though, because so much of Git's source code uses words that would trigger cSpell. Let's add a few words to make the spell checking more useful by reducing the number of false positives. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-30vscode: use 8-space tabs, no trailing ws, etc for Git's source codeLibravatar Johannes Schindelin1-0/+8
This adds a couple settings for the .c/.h files so that it is easier to conform to Git's conventions while editing the source code. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-30vscode: wrap commit messages at column 72 by defaultLibravatar Johannes Schindelin1-0/+4
When configuring VS Code as core.editor (via `code --wait`), we really want to adhere to the Git conventions of wrapping commit messages. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-30vscode: only overwrite C/C++ settingsLibravatar Johannes Schindelin1-3/+20
The C/C++ settings are special, as they are the only generated VS Code configurations that *will* change over the course of Git's development, e.g. when a new constant is defined. Therefore, let's only update the C/C++ settings, also to prevent user modifications from being overwritten. Ideally, we would keep user modifications in the C/C++ settings, but that would require parsing JSON, a task for which a Unix shell script is distinctly unsuited. So we write out .new files instead, and warn the user if they may want to reconcile their changes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-30vscode: hard-code a couple definesLibravatar Johannes Schindelin1-1/+13
Sadly, we do not get all of the definitions via ALL_CFLAGS. Some defines are passed to GCC *only* when compiling specific files, such as git.o. Let's just hard-code them into the script for the time being. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-30contrib: add a script to initialize VS Code configurationLibravatar Johannes Schindelin3-0/+180
VS Code is a lightweight but powerful source code editor which runs on your desktop and is available for Windows, macOS and Linux. Among other languages, it has support for C/C++ via an extension, which offers to not only build and debug the code, but also Intellisense, i.e. code-aware completion and similar niceties. This patch adds a script that helps set up the environment to work effectively with VS Code: simply run the Unix shell script contrib/vscode/init.sh, which creates the relevant files, and open the top level folder of Git's source code in VS Code. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-18Merge branch 'tb/grep-column'Libravatar Junio C Hamano2-3/+11
"git grep" learned the "--column" option that gives not just the line number but the column number of the hit. * tb/grep-column: contrib/git-jump/git-jump: jump to exact location grep.c: add configuration variables to show matched option builtin/grep.c: add '--column' option to 'git-grep(1)' grep.c: display column number of first match grep.[ch]: extend grep_opt to allow showing matched column grep.c: expose {,inverted} match column in match_line() Documentation/config.txt: camel-case lineNumber for consistency