summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-07-06Merge branch 'en/sparse-status'Libravatar Junio C Hamano3-2/+67
"git status" learned to report the status of sparse checkout. * en/sparse-status: git-prompt: include sparsity state as well git-prompt: document how in-progress operations affect the prompt wt-status: show sparse checkout status as well
2020-07-06Merge branch 'ps/ref-transaction-hook'Libravatar Junio C Hamano4-2/+244
A new hook. * ps/ref-transaction-hook: refs: implement reference transaction hook
2020-07-06Merge branch 'bc/sha-256-part-2'Libravatar Junio C Hamano45-246/+694
SHA-256 migration work continues. * bc/sha-256-part-2: (44 commits) remote-testgit: adapt for object-format bundle: detect hash algorithm when reading refs t5300: pass --object-format to git index-pack t5704: send object-format capability with SHA-256 t5703: use object-format serve option t5702: offer an object-format capability in the test t/helper: initialize the repository for test-sha1-array remote-curl: avoid truncating refs with ls-remote t1050: pass algorithm to index-pack when outside repo builtin/index-pack: add option to specify hash algorithm remote-curl: detect algorithm for dumb HTTP by size builtin/ls-remote: initialize repository based on fetch t5500: make hash independent serve: advertise object-format capability for protocol v2 connect: parse v2 refs with correct hash algorithm connect: pass full packet reader when parsing v2 refs Documentation/technical: document object-format for protocol v2 t1302: expect repo format version 1 for SHA-256 builtin/show-index: provide options to determine hash algo t5302: modernize test formatting ...
2020-06-29The sixth batchLibravatar Junio C Hamano1-0/+20
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-29Merge branch 'sk/diff-files-show-i-t-a-as-new'Libravatar Junio C Hamano2-8/+52
"git diff-files" has been taught to say paths that are marked as intent-to-add are new files, not modified from an empty blob. * sk/diff-files-show-i-t-a-as-new: diff-files: treat "i-t-a" files as "not-in-index"
2020-06-29Merge branch 'rs/commit-reach-leakfix'Libravatar Junio C Hamano1-1/+4
Leakfix. * rs/commit-reach-leakfix: commit-reach: plug minor memory leak after using is_descendant_of()
2020-06-29Merge branch 'rs/pull-leakfix'Libravatar Junio C Hamano1-0/+1
Leakfix. * rs/pull-leakfix: pull: plug minor memory leak after using is_descendant_of()
2020-06-29Merge branch 'rs/retire-strbuf-write-fd'Libravatar Junio C Hamano3-7/+3
A misdesigned strbuf_write_fd() function has been retired. * rs/retire-strbuf-write-fd: strbuf: remove unreferenced strbuf_write_fd method. bugreport.c: replace strbuf_write_fd with write_in_full
2020-06-29Merge branch 'dl/diff-usage-comment-update'Libravatar Junio C Hamano1-3/+12
An in-code comment in "git diff" has been updated. * dl/diff-usage-comment-update: builtin/diff: fix botched update of usage comment builtin/diff: update usage comment
2020-06-29Merge branch 'xl/upgrade-repo-format'Libravatar Junio C Hamano11-11/+75
Allow runtime upgrade of the repository format version, which needs to be done carefully. There is a rather unpleasant backward compatibility worry with the last step of this series, but it is the right thing to do in the longer term. * xl/upgrade-repo-format: check_repository_format_gently(): refuse extensions for old repositories sparse-checkout: upgrade repository to version 1 when enabling extension fetch: allow adding a filter after initial clone repository: add a helper function to perform repository format upgrade
2020-06-25The fifth batchLibravatar Junio C Hamano1-0/+30
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-25Merge branch 'pb/t4014-unslave'Libravatar Junio C Hamano1-4/+4
A branch name used in a test has been clarified to match what is going on. * pb/t4014-unslave: t4014: do not use "slave branch" nomenclature
2020-06-25Merge branch 'jt/cdn-offload'Libravatar Junio C Hamano19-167/+750
The "fetch/clone" protocol has been updated to allow the server to instruct the clients to grab pre-packaged packfile(s) in addition to the packed object data coming over the wire. * jt/cdn-offload: upload-pack: fix a sparse '0 as NULL pointer' warning upload-pack: send part of packfile response as uri fetch-pack: support more than one pack lockfile upload-pack: refactor reading of pack-objects out Documentation: add Packfile URIs design doc Documentation: order protocol v2 sections http-fetch: support fetching packfiles by URL http-fetch: refactor into function http: refactor finish_http_pack_request() http: use --stdin when indexing dumb HTTP pack
2020-06-25Merge branch 'ss/submodule-set-branch-in-c'Libravatar Junio C Hamano2-29/+47
Rewrite of parts of the scripted "git submodule" Porcelain command continues; this time it is "git submodule set-branch" subcommand's turn. * ss/submodule-set-branch-in-c: submodule: port subcommand 'set-branch' from shell to C
2020-06-25Merge branch 'ds/merge-base-is-ancestor-optim'Libravatar Junio C Hamano1-3/+18
"git merge-base --is-ancestor" is taught to take advantage of the commit graph. * ds/merge-base-is-ancestor-optim: commit-reach: use fast logic in repo_in_merge_base commit-reach: create repo_is_descendant_of()
2020-06-25Merge branch 'dl/branch-cleanup'Libravatar Junio C Hamano2-25/+44
Code clean-up around "git branch" with a minor bugfix. * dl/branch-cleanup: branch: don't mix --edit-description t3200: test for specific errors t3200: rename "expected" to "expect"
2020-06-25Merge branch 'cc/upload-pack-data-3'Libravatar Junio C Hamano1-162/+125
Code clean-up in the codepath that serves "git fetch" continues. * cc/upload-pack-data-3: upload-pack: refactor common code into do_got_oid() upload-pack: move oldest_have to upload_pack_data upload-pack: pass upload_pack_data to got_oid() upload-pack: pass upload_pack_data to ok_to_give_up() upload-pack: pass upload_pack_data to send_acks() upload-pack: pass upload_pack_data to process_haves() upload-pack: change allow_unadvertised_object_request to an enum upload-pack: move allow_unadvertised_object_request to upload_pack_data upload-pack: move extra_edge_obj to upload_pack_data upload-pack: move shallow_nr to upload_pack_data upload-pack: pass upload_pack_data to send_unshallow() upload-pack: pass upload_pack_data to deepen_by_rev_list() upload-pack: pass upload_pack_data to deepen() upload-pack: pass upload_pack_data to send_shallow_list()
2020-06-25Merge branch 'ct/diff-with-merge-base-clarification'Libravatar Junio C Hamano4-19/+226
"git diff" used to take arguments in random and nonsense range notation, e.g. "git diff A..B C", "git diff A..B C...D", etc., which has been cleaned up. * ct/diff-with-merge-base-clarification: Documentation: usage for diff combined commits git diff: improve range handling t/t3430: avoid undefined git diff behavior
2020-06-25Merge branch 'en/clean-cleanups'Libravatar Junio C Hamano2-16/+48
Code clean-up of "git clean" resulted in a fix of recent performance regression. * en/clean-cleanups: clean: optimize and document cases where we recurse into subdirectories clean: consolidate handling of ignored parameters dir, clean: avoid disallowed behavior dir: fix a few confusing comments
2020-06-25Merge branch 'jk/complete-git-switch'Libravatar Junio C Hamano2-39/+668
The command line completion (in contrib/) learned to complete options that the "git switch" command takes. * jk/complete-git-switch: completion: improve handling of --orphan option of switch/checkout completion: improve handling of -c/-C and -b/-B in switch/checkout completion: improve handling of --track in switch/checkout completion: improve handling of --detach in checkout completion: improve completion for git switch with no options completion: improve handling of DWIM mode for switch/checkout completion: perform DWIM logic directly in __git_complete_refs completion: extract function __git_dwim_remote_heads completion: replace overloaded track term for __git_complete_refs completion: add tests showing subpar switch/checkout --orphan logic completion: add tests showing subpar -c/C argument completion completion: add tests showing subpar -c/-C startpoint completion completion: add tests showing subpar switch/checkout --track logic completion: add tests showing subar checkout --detach logic completion: add tests showing subpar DWIM logic for switch/checkout completion: add test showing subpar git switch completion
2020-06-23builtin/diff: fix botched update of usage commentLibravatar Denton Liu1-4/+1
In the previous commit, an attempt was made to correct the "N=1, M=0" case. However, the fix was botched and it introduced two half-correct sections by mistake. Combine these half-correct sections into one fully correct section. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22The fourth batchLibravatar Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22Merge branch 'en/sparse-with-submodule-doc'Libravatar Junio C Hamano1-4/+26
The effect of sparse checkout settings on submodules is documented. * en/sparse-with-submodule-doc: git-sparse-checkout: clarify interactions with submodules
2020-06-22Merge branch 'es/worktree-duplicate-paths'Libravatar Junio C Hamano4-36/+141
The same worktree directory must be registered only once, but "git worktree move" allowed this invariant to be violated, which has been corrected. * es/worktree-duplicate-paths: worktree: make "move" refuse to move atop missing registered worktree worktree: generalize candidate worktree path validation worktree: prune linked worktree referencing main worktree path worktree: prune duplicate entries referencing same worktree path worktree: make high-level pruning re-usable worktree: give "should be pruned?" function more meaningful name worktree: factor out repeated string literal
2020-06-22Merge branch 'jt/redact-all-cookies'Libravatar Junio C Hamano3-43/+39
The interface to redact sensitive information in the trace output has been simplified. * jt/redact-all-cookies: http: redact all cookies, teach GIT_TRACE_REDACT=0
2020-06-22Merge branch 'cc/upload-pack-data-2'Libravatar Junio C Hamano1-89/+110
Further code clean-up. * cc/upload-pack-data-2: upload-pack: move pack_objects_hook to upload_pack_data upload-pack: move allow_sideband_all to upload_pack_data upload-pack: move allow_ref_in_want to upload_pack_data upload-pack: move allow_filter to upload_pack_data upload-pack: move keepalive to upload_pack_data upload-pack: pass upload_pack_data to upload_pack_config() upload-pack: change multi_ack to an enum upload-pack: move multi_ack to upload_pack_data upload-pack: move filter_capability_requested to upload_pack_data upload-pack: move use_sideband to upload_pack_data upload-pack: move static vars to upload_pack_data upload-pack: annotate upload_pack_data fields upload-pack: actually use some upload_pack_data bitfields
2020-06-22diff-files: treat "i-t-a" files as "not-in-index"Libravatar Srinidhi Kaushik2-8/+52
The `diff-files' command and related commands which call the function `cmd_diff_files()', consider the "intent-to-add" files as a part of the index when comparing the work-tree against it. This was previously addressed in commits [1] and [2] by turning the option `--ita-invisible-in-index' (introduced in [3]) on by default. For `diff-files' (and `add -p' as a consequence) to show the i-t-a files as as new, `ita_invisible_in_index' will be enabled by default here as well. [1] 0231ae71d3 (diff: turn --ita-invisible-in-index on by default, 2018-05-26) [2] 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist in index", 2016-10-24) [3] b42b451919 (diff: add --ita-[in]visible-in-index, 2016-10-24) Signed-off-by: Srinidhi Kaushik <shrinidhi.kaushik@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22git-prompt: include sparsity state as wellLibravatar Elijah Newren1-2/+20
git-prompt includes the current branch, a bunch of single character mini-state displayers, and some much longer in-progress state notifications. The current branch is always shown. The single character mini-state displayers are all off by default (they are not self explanatory) but each has an environment variable for turning it on. The in-progress state notifications provide no configuration options for turning them off, and can be up to 15 characters long (e.g. "|REBASE (12/18)" or "|CHERRY-PICKING"). The single character mini-state tends to be used for things like "Do you have any stashes in refs/stash?" or "Are you ahead or behind of upstream?". These are things which users can take advantage of but do not affect most normal git operations. The in-progress states, by contrast, suggest the user needs to interact differently and may also prevent some normal operations from succeeding (e.g. git switch may show an error instead of switching branches). Sparsity is like the in-progress states in that it suggests a fundamental different interaction with the repository (many of the files from the repository are not present in your working copy!). A few commits ago added sparsity information to wt_longstatus_print_state(), grouping it with other in-progress state displays. We do similarly here with the prompt and show the extra state, by default, with an extra |SPARSE This state can be present simultaneously with the in-progress states, in which case it will appear before the other states; for example, (branchname|SPARSE|REBASE 6/10) The reason for showing the "|SPARSE" substring before other states is to emphasize those other states. Sparsity is probably not going to change much within a repository, while temporary operations will. So we want the state changes related to temporary operations to be listed last, to make them appear closer to where the user types and make them more likely to be noticed. The fact that sparsity isn't just cached metadata or additional information is what leads us to show it more similarly to the in-progress states, but the fact that sparsity is not transient like the in-progress states might cause some users to want an abbreviated notification of sparsity state or perhaps even be able to turn it off. Allow GIT_PS1_COMPRESSSPARSESTATE to be set to request that it be shortened to a single character ('?'), and GIT_PS1_OMITSPARSESTATE to be set to request that sparsity state be omitted from the prompt entirely. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-22git-prompt: document how in-progress operations affect the promptLibravatar Elijah Newren1-0/+4
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19remote-testgit: adapt for object-formatLibravatar brian m. carlson1-0/+6
When using an algorithm other than SHA-1, we need the remote helper to advertise support for the object-format extension and provide information back to us so that we can properly parse refs and return data. Ensure that the test remote helper understands these extensions. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19bundle: detect hash algorithm when reading refsLibravatar brian m. carlson3-3/+30
Much like with the dumb HTTP transport, there isn't a way to explicitly specify the hash algorithm when dealing with a bundle, so detect the algorithm based on the length of the object IDs in the prerequisites and ref advertisements. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19t5300: pass --object-format to git index-packLibravatar brian m. carlson1-4/+5
git index-pack by default reads the repository to determine the object format. However, when outside of a repository, it's necessary to specify the hash algorithm in use so that the pack can be properly indexed. Add an --object-format argument when invoking git index-pack outside of a repository. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19t5704: send object-format capability with SHA-256Libravatar brian m. carlson1-0/+2
When we speak protocol v2 in this test, we must pass the object-format header if the algorithm is not SHA-1. Otherwise, git upload-pack fails because the hash algorithm doesn't match and not because we've failed to speak the protocol correctly. Pass the header so that our assertions test what we're really interested in. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19t5703: use object-format serve optionLibravatar brian m. carlson1-5/+14
When we're using an algorithm other than SHA-1, we need to specify the algorithm in use so we don't get a failure with an "unknown format" message. Add a wrapper function that specifies this header if required. Skip specifying this header for SHA-1 to test that it works both with an without this header. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19t5702: offer an object-format capability in the testLibravatar brian m. carlson1-0/+2
In order to make this test work with SHA-256, offer an object-format capability so that both sides use the same algorithm. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19t/helper: initialize the repository for test-sha1-arrayLibravatar brian m. carlson1-0/+3
test-sha1-array uses the_hash_algo under the hood. Since t0064 wants to use the value that is correct for the hash algorithm that we're testing, make sure the test helper initializes the repository to set the_hash_algo correctly. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19remote-curl: avoid truncating refs with ls-remoteLibravatar brian m. carlson1-1/+3
Normally, the remote-curl transport helper is aware of the hash algorithm we're using because we're in a repo with the appropriate hash algorithm set. However, when using git ls-remote outside of a repository, we won't have initialized the hash algorithm properly, so use hash_to_hex_algop to print the ref corresponding to the algorithm we've detected. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19t1050: pass algorithm to index-pack when outside repoLibravatar brian m. carlson1-1/+3
When outside a repository, git index-pack is unable to guess the hash algorithm in use for a pack, since packs don't contain any information on the algorithm in use. Pass an option to index-pack to help it out in this test. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19builtin/index-pack: add option to specify hash algorithmLibravatar brian m. carlson2-0/+16
git index-pack is usually run in a repository, but need not be. Since packs don't contains information on the algorithm in use, instead relying on context, add an option to index-pack to tell it which one we're using in case someone runs it outside of a repository. Since using --stdin necessarily implies a repository, don't allow specifying an object format if it's provided to prevent users from passing an option that won't work. Add documentation for this option. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19remote-curl: detect algorithm for dumb HTTP by sizeLibravatar brian m. carlson2-2/+39
When reading the info/refs file for a repository, we have no explicit way to detect which hash algorithm is in use because the file doesn't provide one. Detect the hash algorithm in use by the size of the first object ID. If we have an empty repository, we don't know what the hash algorithm is on the remote side, so default to whatever the local side has configured. Without doing this, we cannot clone an empty repository since we don't know its hash algorithm. Test this case appropriately, since we currently have no tests for cloning an empty repository with the dumb HTTP protocol. We anonymize the URL like elsewhere in the function in case the user has decided to include a secret in the URL. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19strbuf: remove unreferenced strbuf_write_fd method.Libravatar Randall S. Becker2-6/+0
strbuf_write_fd was only used in bugreport.c. Since that file now uses write_in_full, this method is no longer needed. In addition, strbuf_write_fd did not guard against exceeding MAX_IO_SIZE for the platform, nor provided error handling in the event of a failure if only partial data was written to the file descriptor. Since already write_in_full has this capability and is in general use, it should be used instead. The change impacts strbuf.c and strbuf.h. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19bugreport.c: replace strbuf_write_fd with write_in_fullLibravatar Randall S. Becker1-1/+3
The strbuf_write_fd method did not provide checks for buffers larger than MAX_IO_SIZE. Replacing with write_in_full ensures the entire buffer will always be written to disk or report an error and die. Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19pull: plug minor memory leak after using is_descendant_of()Libravatar René Scharfe1-0/+1
cmd_pull() builds a commit_list to pass a single potential ancestor to is_descendant_of(). The latter leaves the list intact. Release the allocated memory after the call. Leaking in cmd_*() isn't a big deal, but sets a bad example for other users of is_descendant_of(). Signed-off-by: René Scharfe <l.s.r@web.de> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19commit-reach: plug minor memory leak after using is_descendant_of()Libravatar René Scharfe1-1/+4
ref_newer() builds a commit_list to pass a single potential ancestor to is_descendant_of(). The latter leaves the list intact. Release the allocated memory after the call. Signed-off-by: René Scharfe <l.s.r@web.de> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19refs: implement reference transaction hookLibravatar Patrick Steinhardt4-2/+244
The low-level reference transactions used to update references are currently completely opaque to the user. While certainly desirable in most usecases, there are some which might want to hook into the transaction to observe all queued reference updates as well as observing the abortion or commit of a prepared transaction. One such usecase would be to have a set of replicas of a given Git repository, where we perform Git operations on all of the repositories at once and expect the outcome to be the same in all of them. While there exist hooks already for a certain subset of Git commands that could be used to implement a voting mechanism for this, many others currently don't have any mechanism for this. The above scenario is the motivation for the new "reference-transaction" hook that reaches directly into Git's reference transaction mechanism. The hook receives as parameter the current state the transaction was moved to ("prepared", "committed" or "aborted") and gets via its standard input all queued reference updates. While the exit code gets ignored in the "committed" and "aborted" states, a non-zero exit code in the "prepared" state will cause the transaction to be aborted prematurely. Given the usecase described above, a voting mechanism can now be implemented via this hook: as soon as it gets called, it will take all of stdin and use it to cast a vote to a central service. When all replicas of the repository agree, the hook will exit with zero, otherwise it will abort the transaction by returning non-zero. The most important upside is that this will catch _all_ commands writing references at once, allowing to implement strong consistency for reference updates via a single mechanism. In order to test the impact on the case where we don't have any "reference-transaction" hook installed in the repository, this commit introduce two new performance tests for git-update-refs(1). Run against an empty repository, it produces the following results: Test origin/master HEAD -------------------------------------------------------------------- 1400.2: update-ref 2.70(2.10+0.71) 2.71(2.10+0.73) +0.4% 1400.3: update-ref --stdin 0.21(0.09+0.11) 0.21(0.07+0.14) +0.0% The performance test p1400.2 creates, updates and deletes a branch a thousand times, thus averaging runtime of git-update-refs over 3000 invocations. p1400.3 instead calls `git-update-refs --stdin` three times and queues a thousand creations, updates and deletes respectively. As expected, p1400.3 consistently shows no noticeable impact, as for each batch of updates there's a single call to access(3P) for the negative hook lookup. On the other hand, for p1400.2, one can see an impact caused by this patchset. But doing five runs of the performance tests where each one was run with GIT_PERF_REPEAT_COUNT=10, the overhead ranged from -1.5% to +1.1%. These inconsistent performance numbers can be explained by the overhead of spawning 3000 processes. This shows that the overhead of assembling the hook path and executing access(3P) once to check if it's there is mostly outweighed by the operating system's overhead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-19t4014: do not use "slave branch" nomenclatureLibravatar Paolo Bonzini1-4/+4
Git branches have been qualified as topic branches, integration branches, development branches, feature branches, release branches and so on. Git has a branch that is the master *for* development, but it is not the master *of* any "slave branch": Git does not have slave branches, and has never had, except for a single testcase that claims otherwise. :) Independent of any future change to the naming of the "master" branch, removing this sole appearance of the term is a strict improvement: it avoids divisive language, and talking about "feature branch" clarifies which developer workflow the test is trying to emulate. Reported-by: Till Maas <tmaas@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-18builtin/diff: update usage commentLibravatar Denton Liu1-3/+15
A comment in cmd_diff() states that if one tree-ish and no blobs are provided, (the "N=1, M=0" case), it will provide a diff between the tree and the cache. This is incorrect because a diff happens between the tree-ish and the working tree. Remove the `--cached` in the comment so that the correct behavior is shown. Add a new section describing the "N=1, M=0, --cached" behavior. Next, describe the "N=0, M=0, --cached" case, similar to the above since it is undocumented. Finally, fix some spacing issues. Add spaces between each section for consistency and readability. Also, change tabs within the comment into spaces. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-18wt-status: show sparse checkout status as wellLibravatar Elijah Newren2-0/+43
Some of the early feedback of folks trying out sparse-checkouts at $dayjob is that sparse checkouts can sometimes be disorienting; users can forget that they had a sparse-checkout and then wonder where files went. Add some output to 'git status' in the form of a simple line that states: You are in a sparse checkout with 35% of files present. where, obviously, the exact figure changes depending on what percentage of files from the index do not have the SKIP_WORKTREE bit set. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-17The third batchLibravatar Junio C Hamano2-1/+25
Also let's update the DEF_VER in GIT-VERSION-GEN that presuably is not looked at by anybody ;-) Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-17Merge branch 'es/advertise-contribution-doc'Libravatar Junio C Hamano2-2/+6
Doc updates. * es/advertise-contribution-doc: docs: mention MyFirstContribution in more places