Re: [PATCH 0/2] Sparse checkout status

From: Son Luong Ngoc <sluongng@gmail.com>
Date: Jun 17, 2020, 07:40 UTC
Message-ID: <CAL3xRKf+rQuq=j_4NJpNbRq4Rdxz7MjQaxi3c9usS+c615k19Q@mail.gmail.com>

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.

Show 9 quoted lines

> 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@gmail.com/T/#u