Hi Elijah,
> Some of the 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.
I agree with this observation: that the current 'git sparse-checkout' experience
could be a bit 'lost' for end users, who may or may not be familiar
with git's 'arcane magic'.
Currently the only way to verify what's going on is to either run
'tree <repo-root-dir>'
or 'cat .git/info/sparse-checkout' (human-readable but not easy).
> This series adds some output to 'git status' and modifies git-prompt slightly as an attempt
> to help.
This is a great idea but I suggest to put a config/flag to let users
enable/disable this.
Git status is often utilized in automated commands (IDE, shell prompt,
etc...) and there may be
performance implications down the line not being able to skip this bit
of information out.
> For reference, I suspect that in repositories that are large enough that
> people always use sparse-checkouts (e.g. windows or office repos), that this
> isn't a problem. But when the repository is approximately
> linux-kernel-sized, then it is reasonable for some folks to have a full
> checkout. sparse-checkouts, however, can provide various build system and
> IDE performance improvements, so we have a split of users who have
> sparse-checkouts and those who have full checkouts. It's easy for users who
> are bridging in between the two worlds or just trying out sparse-checkouts
> for the first time to get confused.
One of our users noted that the experience is improved when combining
'git worktree' with sparse-checkout.
That way you get the correct sparsity for the topic that you are working on.
In a way, the current sparse-checkout experience is similar to a user
running 'git checkout <rev>' directly
instead of checking out a branch.
It does not feel tangible and reproducible.
I was hoping that these concerns will be addressed once the In-Tree
Sparse-Checkout Definition RFC[1] patch landed.
We should then be able to print out which Definition File(s) (we often
call it manifests) were used,
and ideally, only the top most file(s) in the inheritance tree.
So the ideal experience, in my mind, is something of this sort:
git sc init --cone
# assuming a inherited from b and c
git sc add --in-tree manifest-dir/module-a.manifest
git sc add --in-tree manifest-dir/module-d.manifest
git sc status
Your sparse checkout includes following definition(s):
(1) manifest-dir/module-a.manifest
(2) manifest-dir/module-d.manifest
git sc status --all
Your sparse checkout includes following definition(s):
(1) manifest-dir/module-a.manifest
(2) manifest-dir/module-d.manifest
(3) manifest-dir/module-b.manifest (included by 1)
(4) manifest-dir/module-c.manifest (included by 1)
I have a feeling that the current file skipped percentage prompt is
not that useful or actionable to end-users,
and they would still end up feeling lost/disoriented at the end.
Thanks,
Son Luong.
[1]: https://lore.kernel.org/git/pull.627.git.1588857462.gitgitgadget@xxxxxxxxx/T/#u
