Show progress in 'git read-tree' #200
Conversation
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 <[email protected]>
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 <[email protected]>
derrickstolee
requested review from
garimasi514,
jeffhostetler and
wilbaker
builtin/read-tree.c
Outdated
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
left a comment
jeffhostetler
left a comment
There was a problem hiding this comment.
This is fine as is. However, it would be better if we could use the ce offset trick and give this change a lighter footprint.
Signed-off-by: Derrick Stolee <[email protected]>
derrickstolee
force-pushed
the
read-tree-progress/vfs
branch
from
0a883bc to
e98704e
Compare
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.
4 participants
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.