Show progress in 'git read-tree' #200
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When a large repository has many sparse-checkout patterns, the process for updating the skip-worktree bits can take long enough that a user gets confused why nothing is happening. Update the clear_ce_flags() method to write progress. Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
The read-tree builtin has a --verbose option that signals to show progress and other data while updating the index. Update this to be on by default when stderr is a terminal window. This will help tools like 'git sparse-checkout' to automatically benefit from progress indicators when a user runs these commands. Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee
requested review from
jeffhostetler,
garimasi514 and
wilbaker
garimasi514
reviewed
Sep 24, 2019
wilbaker
reviewed
Sep 24, 2019
| @@ -162,6 +162,7 @@ int cmd_read_tree(int argc, const char **argv, const char *cmd_prefix) | |||
| opts.head_idx = -1; | |||
| opts.src_index = &the_index; | |||
| opts.dst_index = &the_index; | |||
| opts.verbose_update = isatty(2); | |||
There was a problem hiding this comment.
Should opts.verbose_update be false if --quiet is specified?
There was a problem hiding this comment.
It appears that quiet means something other than "not verbose". This is non-obvious.
The quiet member in struct unpack_trees_options only toggles the output of error messages. This is different than the verbose_update member which toggles the existing progress indicators during the checkout.
Today, if you say git read-tree --verbose --quiet -mu HEAD, then you will still get progress indicators during the "Checking out files" step.
There was a problem hiding this comment.
Thanks for the details here, I couldn't quite figure out what --quiet was controlling.
jeffhostetler
approved these changes
Sep 25, 2019
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
derrickstolee
force-pushed
the
read-tree-progress/vfs
branch
from
0a883bc
to
e98704e
Compare
derrickstolee
added a commit
to microsoft/scalar
that referenced
this pull request
Sep 26, 2019
See microsoft/git#200 for details. Resolves microsoft/git#181. This will give users more ideas of how long a command will take when modifying the sparse-checkout definition. In particular, we will notice if clear_ce_flags() is suddenly slow.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When updating a sparse-checkout, it can be confusing what is taking so much time. Usually, it is the
git read-tree -mu HEADcall.This PR adds progress to the 'git read-tree' builtin by
Here is an example of output for the Linux kernel repo:
Resolves #181.