[PATCH 0/2] Sparse checkout status

[PATCH 0/2] Sparse checkout status

[Elijah Newren via GitGitGadget]

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. This series adds
some output to 'git status' and modifies git-prompt slightly as an attempt
to help.

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.

Elijah Newren (2):
  [RFC] wt-status: show sparse checkout status as well
  [RFC] git-prompt: include sparsity state as well

 contrib/completion/git-prompt.sh |  7 ++++++-
 wt-status.c                      | 35 ++++++++++++++++++++++++++++++++
 wt-status.h                      |  1 +
 3 files changed, 42 insertions(+), 1 deletion(-)


base-commit: eebb51ba8cab97c0b3f3f18eaab7796803b8494b
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-808%2Fnewren%2Fsparse-checkout-status-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-808/newren/sparse-checkout-status-v1
Pull-Request: https://github.com/git/git/pull/808
-- 
gitgitgadget

[PATCH 1/2] [RFC] wt-status: show sparse checkout status as well

[Elijah Newren via GitGitGadget]

From: Elijah Newren <newren@gmail.com>

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>
---
 wt-status.c | 35 +++++++++++++++++++++++++++++++++++
 wt-status.h |  1 +
 2 files changed, 36 insertions(+)

diff --git a/wt-status.c b/wt-status.c
index 98dfa6f73f9..687d2ab1ba1 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1484,6 +1484,16 @@ static void show_bisect_in_progress(struct wt_status *s,
 	wt_longstatus_print_trailer(s);
 }
 
+static void show_sparse_checkout_in_use(struct wt_status *s,
+					const char *color)
+{
+	if (s->state.sparse_checkout_percentage != -1)
+		status_printf_ln(s, color,
+				 _("You are in a sparse checkout with %d%% of tracked files present."),
+				 s->state.sparse_checkout_percentage);
+	wt_longstatus_print_trailer(s);
+}
+
 /*
  * Extract branch information from rebase/bisect
  */
@@ -1623,6 +1633,27 @@ int wt_status_check_bisect(const struct worktree *wt,
 	return 0;
 }
 
+static void wt_status_check_sparse_checkout(struct repository *r,
+					    struct wt_status_state *state)
+{
+	int skip_worktree = 0;
+	int i;
+
+	if (!core_apply_sparse_checkout) {
+		state->sparse_checkout_percentage = -1;
+		return;
+	}
+
+	for (i = 0; i < r->index->cache_nr; i++) {
+		struct cache_entry *ce = r->index->cache[i];
+		if (ce_skip_worktree(ce))
+			skip_worktree++;
+	}
+
+	state->sparse_checkout_percentage =
+		100 - (100 * skip_worktree)/r->index->cache_nr;
+}
+
 void wt_status_get_state(struct repository *r,
 			 struct wt_status_state *state,
 			 int get_detached_from)
@@ -1658,6 +1689,7 @@ void wt_status_get_state(struct repository *r,
 	}
 	if (get_detached_from)
 		wt_status_get_detached_from(r, state);
+	wt_status_check_sparse_checkout(r, state);
 }
 
 static void wt_longstatus_print_state(struct wt_status *s)
@@ -1681,6 +1713,9 @@ static void wt_longstatus_print_state(struct wt_status *s)
 		show_revert_in_progress(s, state_color);
 	if (state->bisect_in_progress)
 		show_bisect_in_progress(s, state_color);
+
+	if (state->sparse_checkout_percentage != -1)
+		show_sparse_checkout_in_use(s, state_color);
 }
 
 static void wt_longstatus_print(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 73ab5d4da1c..4550004003a 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -90,6 +90,7 @@ struct wt_status_state {
 	int bisect_in_progress;
 	int revert_in_progress;
 	int detached_at;
+	int sparse_checkout_percentage; /* -1 == not in sparse checkout */
 	char *branch;
 	char *onto;
 	char *detached_from;
-- 
gitgitgadget

[PATCH 2/2] [RFC] git-prompt: include sparsity state as well

[Elijah Newren via GitGitGadget]

From: Elijah Newren <newren@gmail.com>

The current git prompt includes a lot of possible state information, from
various flavors of rebases to cherry-picks, or merges, or bisects.  Add
sparsity as another state flavor (though one which can be present
simultaneously with any of rebase/cherry-pick/merge/bisect).  This extra
state is shown with an extra
    |SPARSE
substring before the other states.  (Sparsity is probably not going to
change much within a repository, while temporary operations will.  So we
want the temporary operation related state changes to be listed last, to
make them appear closer to where the user types and make them more
likely to be noticed.)  Thus, for example, the prompt might look like:
    (branchname|SPARSE|REBASE 6/10)

Signed-off-by: Elijah Newren <newren@gmail.com>
---
 contrib/completion/git-prompt.sh | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 014cd7c3cfc..3e7344a4014 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -421,6 +421,11 @@ __git_ps1 ()
 		return $exit
 	fi
 
+	local sparse=""
+	if [ "$(git config --bool core.sparseCheckout)" == "true" ]; then
+	    sparse="|SPARSE"
+	fi
+
 	local r=""
 	local b=""
 	local step=""
@@ -543,7 +548,7 @@ __git_ps1 ()
 	fi
 
 	local f="$w$i$s$u"
-	local gitstring="$c$b${f:+$z$f}$r$p"
+	local gitstring="$c$b${f:+$z$f}${sparse}$r$p"
 
 	if [ $pcmode = yes ]; then
 		if [ "${__git_printf_supports_v-}" != yes ]; then
-- 
gitgitgadget

Re: [PATCH 1/2] [RFC] wt-status: show sparse checkout status as well

[Derrick Stolee]

On 6/16/2020 7:33 PM, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@gmail.com>
> 
> 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.

I like this idea.

Aside: I think there was some ideas around a "git sparse-checkout stats"
subcommand that would help users identify how large their sparse-checkout
definition is compared to the full index. That would also want to drill
down into directories, so it would need to be more advanced than what you
have here.

There is some prior work in the "gvfs health" commmand in VFS for Git.
We use this to help users self-diagnose when they have "over hydrated"
their working directory. Here is a sample use:

  /c/_git/t/ForTests/src (master)
  $ gvfs health
  
  Gathering repository data...
  
  Health of directory:
  Total files in HEAD commit:           548 | 100%
  Files managed by VFS for Git (fast):   30 |   5%
  Files managed by Git:                   1 |   0%
  
  Total hydration percentage:                   6%
  
  Most hydrated top level directories:
   19 / 524 | GVFS
    0 / 8   | GitHooksLoader
    0 / 3   | Scripts
  
  Repository status: OK
  
  /c/_git/t/ForTests/src (master)
  $ cd GVFS
  
  /c/_git/t/ForTests/src/GVFS (master)
  $ gvfs health
  
  Gathering repository data...
  
  Health of directory: GVFS/
  Total files in HEAD commit:           524 | 100%
  Files managed by VFS for Git (fast):   19 |   4%
  Files managed by Git:                   0 |   0%
  
  Total hydration percentage:                   4%
  
  Most hydrated top level directories:
   0 / 33 | FastFetch
   0 / 92 | GVFS.Common
   0 / 97 | GVFS.FunctionalTests
   0 / 22 | GVFS.GVFlt
   0 / 7  | GVFS.Hooks
  
  Repository status: OK

This is just a reference for something that has been helpful
for some users. In VFS for Git, the hydration is not explicit
but instead implicit by filesystem use. There could still be
some value in the sparse-checkout case.

> 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>
> ---
>  wt-status.c | 35 +++++++++++++++++++++++++++++++++++
>  wt-status.h |  1 +
>  2 files changed, 36 insertions(+)
> 
> diff --git a/wt-status.c b/wt-status.c
> index 98dfa6f73f9..687d2ab1ba1 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -1484,6 +1484,16 @@ static void show_bisect_in_progress(struct wt_status *s,
>  	wt_longstatus_print_trailer(s);
>  }
>  
> +static void show_sparse_checkout_in_use(struct wt_status *s,
> +					const char *color)
> +{
> +	if (s->state.sparse_checkout_percentage != -1)
> +		status_printf_ln(s, color,
> +				 _("You are in a sparse checkout with %d%% of tracked files present."),
> +				 s->state.sparse_checkout_percentage);

There is some concern over breaking third-party tools that
parse "git status". However, we have had the machine-readable
formats out for a long time.

I briefly thought about putting this message to stderr to be
safe, but some tools scan stderr (incorrectly) to say "any
output to stderr must mean an error in the process."

> +	wt_longstatus_print_trailer(s);
> +}
> +
>  /*
>   * Extract branch information from rebase/bisect
>   */
> @@ -1623,6 +1633,27 @@ int wt_status_check_bisect(const struct worktree *wt,
>  	return 0;
>  }
>  
> +static void wt_status_check_sparse_checkout(struct repository *r,
> +					    struct wt_status_state *state)
> +{
> +	int skip_worktree = 0;
> +	int i;
> +
> +	if (!core_apply_sparse_checkout) {

Since this method is static, we can assume that it is only
called after the index was loaded, which requires reading
the config and initializing this value. Good.

> +		state->sparse_checkout_percentage = -1;
> +		return;
> +	}
> +
> +	for (i = 0; i < r->index->cache_nr; i++) {
> +		struct cache_entry *ce = r->index->cache[i];
> +		if (ce_skip_worktree(ce))
> +			skip_worktree++;
> +	}
> +
> +	state->sparse_checkout_percentage =
> +		100 - (100 * skip_worktree)/r->index->cache_nr;
> +}
> +
>  void wt_status_get_state(struct repository *r,
>  			 struct wt_status_state *state,
>  			 int get_detached_from)
> @@ -1658,6 +1689,7 @@ void wt_status_get_state(struct repository *r,
>  	}
>  	if (get_detached_from)
>  		wt_status_get_detached_from(r, state);
> +	wt_status_check_sparse_checkout(r, state);
>  }
>  
>  static void wt_longstatus_print_state(struct wt_status *s)
> @@ -1681,6 +1713,9 @@ static void wt_longstatus_print_state(struct wt_status *s)
>  		show_revert_in_progress(s, state_color);
>  	if (state->bisect_in_progress)
>  		show_bisect_in_progress(s, state_color);
> +
> +	if (state->sparse_checkout_percentage != -1)
> +		show_sparse_checkout_in_use(s, state_color);
>  }
>  
>  static void wt_longstatus_print(struct wt_status *s)
> diff --git a/wt-status.h b/wt-status.h
> index 73ab5d4da1c..4550004003a 100644
> --- a/wt-status.h
> +++ b/wt-status.h
> @@ -90,6 +90,7 @@ struct wt_status_state {
>  	int bisect_in_progress;
>  	int revert_in_progress;
>  	int detached_at;
> +	int sparse_checkout_percentage; /* -1 == not in sparse checkout */

My only complaint is that maybe this "-1" should be a
#define macro with a name such as SPARSE_CHECKOUT_DISABLED.

Thanks,
-Stolee

Re: [PATCH 1/2] [RFC] wt-status: show sparse checkout status as well

[Elijah Newren]

On Wed, Jun 17, 2020 at 7:50 AM Derrick Stolee <stolee@gmail.com> wrote:
>
> On 6/16/2020 7:33 PM, Elijah Newren via GitGitGadget wrote:
> > From: Elijah Newren <newren@gmail.com>
> >
> > 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.
>
> I like this idea.
>
> Aside: I think there was some ideas around a "git sparse-checkout stats"
> subcommand that would help users identify how large their sparse-checkout
> definition is compared to the full index. That would also want to drill
> down into directories, so it would need to be more advanced than what you
> have here.

Yeah having an "info" or "status" or "stats" subcommand to
sparse-checkout I think would make sense.  I think having some simple
message of some kind in "git status" would help alert/remind someone
that they have a sparse checkout, and then they can run some
sparse-checkout command if they want to drill down more.

> There is some prior work in the "gvfs health" commmand in VFS for Git.
> We use this to help users self-diagnose when they have "over hydrated"
> their working directory. Here is a sample use:
>
>   /c/_git/t/ForTests/src (master)
>   $ gvfs health
>
>   Gathering repository data...
>
>   Health of directory:
>   Total files in HEAD commit:           548 | 100%
>   Files managed by VFS for Git (fast):   30 |   5%
>   Files managed by Git:                   1 |   0%
>
>   Total hydration percentage:                   6%
>
>   Most hydrated top level directories:
>    19 / 524 | GVFS
>     0 / 8   | GitHooksLoader
>     0 / 3   | Scripts
>
>   Repository status: OK
>
>   /c/_git/t/ForTests/src (master)
>   $ cd GVFS
>
>   /c/_git/t/ForTests/src/GVFS (master)
>   $ gvfs health
>
>   Gathering repository data...
>
>   Health of directory: GVFS/
>   Total files in HEAD commit:           524 | 100%
>   Files managed by VFS for Git (fast):   19 |   4%
>   Files managed by Git:                   0 |   0%
>
>   Total hydration percentage:                   4%
>
>   Most hydrated top level directories:
>    0 / 33 | FastFetch
>    0 / 92 | GVFS.Common
>    0 / 97 | GVFS.FunctionalTests
>    0 / 22 | GVFS.GVFlt
>    0 / 7  | GVFS.Hooks
>
>   Repository status: OK
>
> This is just a reference for something that has been helpful
> for some users. In VFS for Git, the hydration is not explicit
> but instead implicit by filesystem use. There could still be
> some value in the sparse-checkout case.

Yeah, I think a `git sparse-checkout` subcommand named 'info' or
'status' with some kind of extra details could be useful, especially
if/when your in-tree sparse checkout definitions are in use.  Our
local 'sparsify' script has an --info flag which reports some
information, though not as detailed as your gvfs health command:

    $ ./sparsify --info
    You are now in a sparse checkout with only 9874 of the 56079 files.
    Sparse modules requested:
      $MODULE_1
      $MODULE_2
    No user-specified additional paths -- tools/scripts/etc.
    Note: You have leftover .gitignore'd files in 197 directories;
          these likely represent build artifacts.
          To remove, run: ./sparsify --update --remove-old-ignores

The last three lines are a repeat of the same output shown at
'./sparsify --modules ...' time; I sent a separate email about that.
The fifth line might bear some explaining and be interesting as well:
since we have a dependency system where users specify some modules
(directories) and then sparsify figures out all the other directories
that those ones depend upon, there isn't flexibility to select
additional files or directories the user may want.  We instead allow
the user to populate .git/info/sparse-checkout-user (not sure I'm
still a fan of the filename/location, but it's what I picked at the
time), which provides a list of additional directories that will be
added to the sparse-checkout on top of the dependencies of the modules
the user specifies.

> > 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>
> > ---
> >  wt-status.c | 35 +++++++++++++++++++++++++++++++++++
> >  wt-status.h |  1 +
> >  2 files changed, 36 insertions(+)
> >
> > diff --git a/wt-status.c b/wt-status.c
> > index 98dfa6f73f9..687d2ab1ba1 100644
> > --- a/wt-status.c
> > +++ b/wt-status.c
> > @@ -1484,6 +1484,16 @@ static void show_bisect_in_progress(struct wt_status *s,
> >       wt_longstatus_print_trailer(s);
> >  }
> >
> > +static void show_sparse_checkout_in_use(struct wt_status *s,
> > +                                     const char *color)
> > +{
> > +     if (s->state.sparse_checkout_percentage != -1)
> > +             status_printf_ln(s, color,
> > +                              _("You are in a sparse checkout with %d%% of tracked files present."),
> > +                              s->state.sparse_checkout_percentage);
>
> There is some concern over breaking third-party tools that
> parse "git status". However, we have had the machine-readable
> formats out for a long time.
>
> I briefly thought about putting this message to stderr to be
> safe, but some tools scan stderr (incorrectly) to say "any
> output to stderr must mean an error in the process."

If we hadn't taken steps over a decade ago (Sep 5, 2009) to avert this
exact problem, then I'd be sympathetic to this concern.  But since
we've had --porcelain for over a decade I'm just not.  Third-party
tools that are parsing git-status have had far more than enough time
to switch, and if they haven't, maybe we could consider changing the
status output to help remind them that they need to.  ;-)

However, there is another point here that is very interesting: I only
modified the long status output, but it's possible I also should have
modified other formats too.  In particular, both the --short and
--porcelain=v2 formats (Porcelain V2 defines an extensible set of
headers and explicitly says that parsers should ignore headers they
don't recognize, so adding a header to it is in line with its design
and won't break existing parsers.)

>
> > +     wt_longstatus_print_trailer(s);
> > +}
> > +
> >  /*
> >   * Extract branch information from rebase/bisect
> >   */
> > @@ -1623,6 +1633,27 @@ int wt_status_check_bisect(const struct worktree *wt,
> >       return 0;
> >  }
> >
> > +static void wt_status_check_sparse_checkout(struct repository *r,
> > +                                         struct wt_status_state *state)
> > +{
> > +     int skip_worktree = 0;
> > +     int i;
> > +
> > +     if (!core_apply_sparse_checkout) {
>
> Since this method is static, we can assume that it is only
> called after the index was loaded, which requires reading
> the config and initializing this value. Good.
>
> > +             state->sparse_checkout_percentage = -1;
> > +             return;
> > +     }
> > +
> > +     for (i = 0; i < r->index->cache_nr; i++) {
> > +             struct cache_entry *ce = r->index->cache[i];
> > +             if (ce_skip_worktree(ce))
> > +                     skip_worktree++;
> > +     }
> > +
> > +     state->sparse_checkout_percentage =
> > +             100 - (100 * skip_worktree)/r->index->cache_nr;
> > +}
> > +
> >  void wt_status_get_state(struct repository *r,
> >                        struct wt_status_state *state,
> >                        int get_detached_from)
> > @@ -1658,6 +1689,7 @@ void wt_status_get_state(struct repository *r,
> >       }
> >       if (get_detached_from)
> >               wt_status_get_detached_from(r, state);
> > +     wt_status_check_sparse_checkout(r, state);
> >  }
> >
> >  static void wt_longstatus_print_state(struct wt_status *s)
> > @@ -1681,6 +1713,9 @@ static void wt_longstatus_print_state(struct wt_status *s)
> >               show_revert_in_progress(s, state_color);
> >       if (state->bisect_in_progress)
> >               show_bisect_in_progress(s, state_color);
> > +
> > +     if (state->sparse_checkout_percentage != -1)
> > +             show_sparse_checkout_in_use(s, state_color);
> >  }
> >
> >  static void wt_longstatus_print(struct wt_status *s)
> > diff --git a/wt-status.h b/wt-status.h
> > index 73ab5d4da1c..4550004003a 100644
> > --- a/wt-status.h
> > +++ b/wt-status.h
> > @@ -90,6 +90,7 @@ struct wt_status_state {
> >       int bisect_in_progress;
> >       int revert_in_progress;
> >       int detached_at;
> > +     int sparse_checkout_percentage; /* -1 == not in sparse checkout */
>
> My only complaint is that maybe this "-1" should be a
> #define macro with a name such as SPARSE_CHECKOUT_DISABLED.

Good point, I'll update it.

Thanks!
Elijah

[PATCH v2 0/2] Sparse checkout status

[Elijah Newren via GitGitGadget]

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. This series adds
some output to 'git status' and modifies git-prompt slightly as an attempt
to help.

Note that as per discussion on v1, we may want to later add a git
sparse-checkout subcommand named something like 'stats' or 'info' or
'status' that provides more detailed information for users to dig deeper.
That would be an additional improvement for helping users find out more
information once they realize or remember they are in a sparse checkout,
this is just aimed at giving them a simple reminder.

Changes since v1:

 * Replaced the -1 magic constant with SPARSE_CHECKOUT_DISABLED
 * Fixed a possible division by 0 (when there are no entries in the index
   AND sparse checkout is enabled; not sure when that'd ever happen but
   still better to guard against...)
 * Slight wording tweaks for the git-prompt commit message
 * Removed the RFC label

Elijah Newren (2):
  wt-status: show sparse checkout status as well
  git-prompt: include sparsity state as well

 contrib/completion/git-prompt.sh |  7 +++++-
 wt-status.c                      | 41 ++++++++++++++++++++++++++++++++
 wt-status.h                      |  2 ++
 3 files changed, 49 insertions(+), 1 deletion(-)


base-commit: b3d7a52fac39193503a0b6728771d1bf6a161464
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-808%2Fnewren%2Fsparse-checkout-status-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-808/newren/sparse-checkout-status-v2
Pull-Request: https://github.com/git/git/pull/808

Range-diff vs v1:

 1:  462cee857ef ! 1:  e266bc39d99 [RFC] wt-status: show sparse checkout status as well
     @@ Metadata
      Author: Elijah Newren <newren@gmail.com>
      
       ## Commit message ##
     -    [RFC] wt-status: show sparse checkout status as well
     +    wt-status: show sparse checkout status as well
      
          Some of the early feedback of folks trying out sparse-checkouts at
          $dayjob is that sparse checkouts can sometimes be disorienting; users
     @@ wt-status.c: static void show_bisect_in_progress(struct wt_status *s,
      +static void show_sparse_checkout_in_use(struct wt_status *s,
      +					const char *color)
      +{
     -+	if (s->state.sparse_checkout_percentage != -1)
     -+		status_printf_ln(s, color,
     -+				 _("You are in a sparse checkout with %d%% of tracked files present."),
     -+				 s->state.sparse_checkout_percentage);
     ++	if (s->state.sparse_checkout_percentage == SPARSE_CHECKOUT_DISABLED)
     ++		return;
     ++
     ++	status_printf_ln(s, color,
     ++			 _("You are in a sparse checkout with %d%% of tracked files present."),
     ++			 s->state.sparse_checkout_percentage);
      +	wt_longstatus_print_trailer(s);
      +}
      +
     @@ wt-status.c: int wt_status_check_bisect(const struct worktree *wt,
      +	int skip_worktree = 0;
      +	int i;
      +
     -+	if (!core_apply_sparse_checkout) {
     -+		state->sparse_checkout_percentage = -1;
     ++	if (!core_apply_sparse_checkout || r->index->cache_nr == 0) {
     ++		/*
     ++		 * Don't compute percentage of checked out files if we
     ++		 * aren't in a sparse checkout or would get division by 0.
     ++		 */
     ++		state->sparse_checkout_percentage = SPARSE_CHECKOUT_DISABLED;
      +		return;
      +	}
      +
     @@ wt-status.c: static void wt_longstatus_print_state(struct wt_status *s)
       	if (state->bisect_in_progress)
       		show_bisect_in_progress(s, state_color);
      +
     -+	if (state->sparse_checkout_percentage != -1)
     ++	if (state->sparse_checkout_percentage != SPARSE_CHECKOUT_DISABLED)
      +		show_sparse_checkout_in_use(s, state_color);
       }
       
       static void wt_longstatus_print(struct wt_status *s)
      
       ## wt-status.h ##
     +@@ wt-status.h: enum wt_status_format {
     + 
     + #define HEAD_DETACHED_AT _("HEAD detached at ")
     + #define HEAD_DETACHED_FROM _("HEAD detached from ")
     ++#define SPARSE_CHECKOUT_DISABLED -1
     + 
     + struct wt_status_state {
     + 	int merge_in_progress;
      @@ wt-status.h: struct wt_status_state {
       	int bisect_in_progress;
       	int revert_in_progress;
       	int detached_at;
     -+	int sparse_checkout_percentage; /* -1 == not in sparse checkout */
     ++	int sparse_checkout_percentage; /* SPARSE_CHECKOUT_DISABLED if not sparse */
       	char *branch;
       	char *onto;
       	char *detached_from;
 2:  64613ad7ad6 ! 2:  17254b30a5b [RFC] git-prompt: include sparsity state as well
     @@ Metadata
      Author: Elijah Newren <newren@gmail.com>
      
       ## Commit message ##
     -    [RFC] git-prompt: include sparsity state as well
     +    git-prompt: include sparsity state as well
      
     -    The current git prompt includes a lot of possible state information, from
     -    various flavors of rebases to cherry-picks, or merges, or bisects.  Add
     +    The current git prompt includes a lot of possible state information from
     +    cherry-picks, merges, bisects, and various flavors of rebases.  Add
          sparsity as another state flavor (though one which can be present
          simultaneously with any of rebase/cherry-pick/merge/bisect).  This extra
          state is shown with an extra
              |SPARSE
     -    substring before the other states.  (Sparsity is probably not going to
     -    change much within a repository, while temporary operations will.  So we
     -    want the temporary operation related state changes to be listed last, to
     -    make them appear closer to where the user types and make them more
     -    likely to be noticed.)  Thus, for example, the prompt might look like:
     +    substring before the other states, providing a prompt that looks like:
              (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.
     +
          Signed-off-by: Elijah Newren <newren@gmail.com>
      
       ## contrib/completion/git-prompt.sh ##

-- 
gitgitgadget

[PATCH v2 1/2] wt-status: show sparse checkout status as well

[Elijah Newren via GitGitGadget]

From: Elijah Newren <newren@gmail.com>

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>
---
 wt-status.c | 41 +++++++++++++++++++++++++++++++++++++++++
 wt-status.h |  2 ++
 2 files changed, 43 insertions(+)

diff --git a/wt-status.c b/wt-status.c
index 98dfa6f73f9..c560cbe860a 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1484,6 +1484,18 @@ static void show_bisect_in_progress(struct wt_status *s,
 	wt_longstatus_print_trailer(s);
 }
 
+static void show_sparse_checkout_in_use(struct wt_status *s,
+					const char *color)
+{
+	if (s->state.sparse_checkout_percentage == SPARSE_CHECKOUT_DISABLED)
+		return;
+
+	status_printf_ln(s, color,
+			 _("You are in a sparse checkout with %d%% of tracked files present."),
+			 s->state.sparse_checkout_percentage);
+	wt_longstatus_print_trailer(s);
+}
+
 /*
  * Extract branch information from rebase/bisect
  */
@@ -1623,6 +1635,31 @@ int wt_status_check_bisect(const struct worktree *wt,
 	return 0;
 }
 
+static void wt_status_check_sparse_checkout(struct repository *r,
+					    struct wt_status_state *state)
+{
+	int skip_worktree = 0;
+	int i;
+
+	if (!core_apply_sparse_checkout || r->index->cache_nr == 0) {
+		/*
+		 * Don't compute percentage of checked out files if we
+		 * aren't in a sparse checkout or would get division by 0.
+		 */
+		state->sparse_checkout_percentage = SPARSE_CHECKOUT_DISABLED;
+		return;
+	}
+
+	for (i = 0; i < r->index->cache_nr; i++) {
+		struct cache_entry *ce = r->index->cache[i];
+		if (ce_skip_worktree(ce))
+			skip_worktree++;
+	}
+
+	state->sparse_checkout_percentage =
+		100 - (100 * skip_worktree)/r->index->cache_nr;
+}
+
 void wt_status_get_state(struct repository *r,
 			 struct wt_status_state *state,
 			 int get_detached_from)
@@ -1658,6 +1695,7 @@ void wt_status_get_state(struct repository *r,
 	}
 	if (get_detached_from)
 		wt_status_get_detached_from(r, state);
+	wt_status_check_sparse_checkout(r, state);
 }
 
 static void wt_longstatus_print_state(struct wt_status *s)
@@ -1681,6 +1719,9 @@ static void wt_longstatus_print_state(struct wt_status *s)
 		show_revert_in_progress(s, state_color);
 	if (state->bisect_in_progress)
 		show_bisect_in_progress(s, state_color);
+
+	if (state->sparse_checkout_percentage != SPARSE_CHECKOUT_DISABLED)
+		show_sparse_checkout_in_use(s, state_color);
 }
 
 static void wt_longstatus_print(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 73ab5d4da1c..f1fa0ec1a75 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -79,6 +79,7 @@ enum wt_status_format {
 
 #define HEAD_DETACHED_AT _("HEAD detached at ")
 #define HEAD_DETACHED_FROM _("HEAD detached from ")
+#define SPARSE_CHECKOUT_DISABLED -1
 
 struct wt_status_state {
 	int merge_in_progress;
@@ -90,6 +91,7 @@ struct wt_status_state {
 	int bisect_in_progress;
 	int revert_in_progress;
 	int detached_at;
+	int sparse_checkout_percentage; /* SPARSE_CHECKOUT_DISABLED if not sparse */
 	char *branch;
 	char *onto;
 	char *detached_from;
-- 
gitgitgadget

[PATCH v2 2/2] git-prompt: include sparsity state as well

[Elijah Newren via GitGitGadget]

From: Elijah Newren <newren@gmail.com>

The current git prompt includes a lot of possible state information from
cherry-picks, merges, bisects, and various flavors of rebases.  Add
sparsity as another state flavor (though one which can be present
simultaneously with any of rebase/cherry-pick/merge/bisect).  This extra
state is shown with an extra
    |SPARSE
substring before the other states, providing a prompt that looks like:
    (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.

Signed-off-by: Elijah Newren <newren@gmail.com>
---
 contrib/completion/git-prompt.sh | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 014cd7c3cfc..3e7344a4014 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -421,6 +421,11 @@ __git_ps1 ()
 		return $exit
 	fi
 
+	local sparse=""
+	if [ "$(git config --bool core.sparseCheckout)" == "true" ]; then
+	    sparse="|SPARSE"
+	fi
+
 	local r=""
 	local b=""
 	local step=""
@@ -543,7 +548,7 @@ __git_ps1 ()
 	fi
 
 	local f="$w$i$s$u"
-	local gitstring="$c$b${f:+$z$f}$r$p"
+	local gitstring="$c$b${f:+$z$f}${sparse}$r$p"
 
 	if [ $pcmode = yes ]; then
 		if [ "${__git_printf_supports_v-}" != yes ]; then
-- 
gitgitgadget

Re: [PATCH v2 0/2] Sparse checkout status

[Junio C Hamano]

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> 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. This series adds
> some output to 'git status' and modifies git-prompt slightly as an attempt
> to help.
>
> Note that as per discussion on v1, we may want to later add a git
> sparse-checkout subcommand named something like 'stats' or 'info' or
> 'status' that provides more detailed information for users to dig deeper.
> That would be an additional improvement for helping users find out more
> information once they realize or remember they are in a sparse checkout,
> this is just aimed at giving them a simple reminder.
>
> Changes since v1:
>
>  * Replaced the -1 magic constant with SPARSE_CHECKOUT_DISABLED
>  * Fixed a possible division by 0 (when there are no entries in the index
>    AND sparse checkout is enabled; not sure when that'd ever happen but
>    still better to guard against...)
>  * Slight wording tweaks for the git-prompt commit message
>  * Removed the RFC label
>
> Elijah Newren (2):
>   wt-status: show sparse checkout status as well
>   git-prompt: include sparsity state as well
>
>  contrib/completion/git-prompt.sh |  7 +++++-
>  wt-status.c                      | 41 ++++++++++++++++++++++++++++++++
>  wt-status.h                      |  2 ++
>  3 files changed, 49 insertions(+), 1 deletion(-)

Any change to Documentation/git-status.txt?

Re: [PATCH v2 0/2] Sparse checkout status

[Elijah Newren]

On Thu, Jun 18, 2020 at 2:46 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > 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. This series adds
> > some output to 'git status' and modifies git-prompt slightly as an attempt
> > to help.
> >
> > Note that as per discussion on v1, we may want to later add a git
> > sparse-checkout subcommand named something like 'stats' or 'info' or
> > 'status' that provides more detailed information for users to dig deeper.
> > That would be an additional improvement for helping users find out more
> > information once they realize or remember they are in a sparse checkout,
> > this is just aimed at giving them a simple reminder.
> >
> > Changes since v1:
> >
> >  * Replaced the -1 magic constant with SPARSE_CHECKOUT_DISABLED
> >  * Fixed a possible division by 0 (when there are no entries in the index
> >    AND sparse checkout is enabled; not sure when that'd ever happen but
> >    still better to guard against...)
> >  * Slight wording tweaks for the git-prompt commit message
> >  * Removed the RFC label
> >
> > Elijah Newren (2):
> >   wt-status: show sparse checkout status as well
> >   git-prompt: include sparsity state as well
> >
> >  contrib/completion/git-prompt.sh |  7 +++++-
> >  wt-status.c                      | 41 ++++++++++++++++++++++++++++++++
> >  wt-status.h                      |  2 ++
> >  3 files changed, 49 insertions(+), 1 deletion(-)
>
> Any change to Documentation/git-status.txt?

Reasonable question; I didn't think of it.  But on a related note, in
the eight years we've had status output for various other forms of
state (in-progress operations like merge, cherry-pick, rebase, or
bisect), these haven't been documented either.  Was that also
oversight, or was there a reason it was left out?

If oversight, should I just document all those others while I'm at it?

Re: [PATCH v2 2/2] git-prompt: include sparsity state as well

[SZEDER Gábor]

On Thu, Jun 18, 2020 at 08:49:58PM +0000, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@gmail.com>
> 
> The current git prompt includes a lot of possible state information from
> cherry-picks, merges, bisects, and various flavors of rebases.  Add
> sparsity as another state flavor (though one which can be present
> simultaneously with any of rebase/cherry-pick/merge/bisect).  This extra
> state is shown with an extra
>     |SPARSE
> substring before the other states, providing a prompt that looks like:
>     (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.

I understand why some users prefer to be reminded when they are in a
repository that uses sparse checkout.  However, perhaps not all users
want to be reminded, and I'm sure that not all users want to increase
the width of their prompt by 7 characters (e.g. in standard-width
terminals).

> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
>  contrib/completion/git-prompt.sh | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
> index 014cd7c3cfc..3e7344a4014 100644
> --- a/contrib/completion/git-prompt.sh
> +++ b/contrib/completion/git-prompt.sh
> @@ -421,6 +421,11 @@ __git_ps1 ()
>  		return $exit
>  	fi
>  
> +	local sparse=""
> +	if [ "$(git config --bool core.sparseCheckout)" == "true" ]; then
> +	    sparse="|SPARSE"

Nit: indentation.

> +	fi
> +
>  	local r=""
>  	local b=""
>  	local step=""
> @@ -543,7 +548,7 @@ __git_ps1 ()
>  	fi
>  
>  	local f="$w$i$s$u"
> -	local gitstring="$c$b${f:+$z$f}$r$p"
> +	local gitstring="$c$b${f:+$z$f}${sparse}$r$p"
>  
>  	if [ $pcmode = yes ]; then
>  		if [ "${__git_printf_supports_v-}" != yes ]; then
> -- 
> gitgitgadget

Re: [PATCH v2 2/2] git-prompt: include sparsity state as well

[Junio C Hamano]

SZEDER Gábor <szeder.dev@gmail.com> writes:

>> +	local sparse=""
>> +	if [ "$(git config --bool core.sparseCheckout)" == "true" ]; then
>> +	    sparse="|SPARSE"
>
> Nit: indentation.

Also, do we want "==" there?  I thought [ ... ] (unlike [[ ... ]])
was a mere synonym for "test", to which "==" is a bug.

Re: [PATCH v2 2/2] git-prompt: include sparsity state as well

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> SZEDER Gábor <szeder.dev@gmail.com> writes:
>
>>> +	local sparse=""
>>> +	if [ "$(git config --bool core.sparseCheckout)" == "true" ]; then
>>> +	    sparse="|SPARSE"
>>
>> Nit: indentation.
>
> Also, do we want "==" there?  I thought [ ... ] (unlike [[ ... ]])
> was a mere synonym for "test", to which "==" is a bug.

Ah, OK, this script is very bash specific so POSIX portability rules
do not matter.  == is just fine as = there.

Sorry for the noise.

Re: [PATCH v2 0/2] Sparse checkout status

[Elijah Newren]

On Thu, Jun 18, 2020 at 4:18 PM Elijah Newren <newren@gmail.com> wrote:
>
> On Thu, Jun 18, 2020 at 2:46 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> >
> > > 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. This series adds
> > > some output to 'git status' and modifies git-prompt slightly as an attempt
> > > to help.
> > >
> > > Note that as per discussion on v1, we may want to later add a git
> > > sparse-checkout subcommand named something like 'stats' or 'info' or
> > > 'status' that provides more detailed information for users to dig deeper.
> > > That would be an additional improvement for helping users find out more
> > > information once they realize or remember they are in a sparse checkout,
> > > this is just aimed at giving them a simple reminder.
> > >
> > > Changes since v1:
> > >
> > >  * Replaced the -1 magic constant with SPARSE_CHECKOUT_DISABLED
> > >  * Fixed a possible division by 0 (when there are no entries in the index
> > >    AND sparse checkout is enabled; not sure when that'd ever happen but
> > >    still better to guard against...)
> > >  * Slight wording tweaks for the git-prompt commit message
> > >  * Removed the RFC label
> > >
> > > Elijah Newren (2):
> > >   wt-status: show sparse checkout status as well
> > >   git-prompt: include sparsity state as well
> > >
> > >  contrib/completion/git-prompt.sh |  7 +++++-
> > >  wt-status.c                      | 41 ++++++++++++++++++++++++++++++++
> > >  wt-status.h                      |  2 ++
> > >  3 files changed, 49 insertions(+), 1 deletion(-)
> >
> > Any change to Documentation/git-status.txt?
>
> Reasonable question; I didn't think of it.  But on a related note, in
> the eight years we've had status output for various other forms of
> state (in-progress operations like merge, cherry-pick, rebase, or
> bisect), these haven't been documented either.  Was that also
> oversight, or was there a reason it was left out?
>
> If oversight, should I just document all those others while I'm at it?

So, I went to look at this.  Documentation/git-status.txt documents in
detail the short status format, the porcelain V1 format, and the
porcelain V2 format.  There are two side comments that the long format
is the default, and that status.submoduleSummary affects the long
output, but the only thing it says to document the contents of the
long format is:
"""
The default, long format, is designed to be human readable,
verbose and descriptive.  Its contents and format are subject to change
at any time.
"""
It would thus feel odd to mention the sparsity status within the long
format when nothing else within that format is documented.  I suspect
that's why it was never added when rebase/merge/cherry-pick/bisect
state notifications were added to the long format.

[PATCH v3 0/3] Sparse checkout status

[Elijah Newren via GitGitGadget]

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. This series adds
some output to 'git status' and modifies git-prompt slightly as an attempt
to help.

(As per discussion on v1, a "git sparse-checkout [status|info|status]" might
supplement the changes from this series later; this is just aimed at giving
users a simple reminder that they are in a sparse checkout.)

Changes since v2:

 * Added an extra commit to document how git-prompt works with in-progress
   state of operations (rebase/merge/cherry-pick/revert/bisect), since I
   want to refer to it for comparison later in the docs.
 * As requested by SZEDER, added the ability to shorten or remove the
   information relating to sparsity state in the git-prompt.
 * Since there are now three options for whether and how to show information
   related to sparsity state, I put a fair amount of effort into reasoning
   among the options about what is a good default and why; I included this
   in the final commit message. (While I suspect that we can easily change
   the default for the prompt in the future based on the big warning at the
   top of git-sparse-checkout.txt, having the rationale up-front for the
   original decision may help us out in the future.)

Elijah Newren (3):
  wt-status: show sparse checkout status as well
  git-prompt: document how in-progress operations affect the prompt
  git-prompt: include sparsity state as well

 contrib/completion/git-prompt.sh | 26 ++++++++++++++++++--
 wt-status.c                      | 41 ++++++++++++++++++++++++++++++++
 wt-status.h                      |  2 ++
 3 files changed, 67 insertions(+), 2 deletions(-)


base-commit: b3d7a52fac39193503a0b6728771d1bf6a161464
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-808%2Fnewren%2Fsparse-checkout-status-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-808/newren/sparse-checkout-status-v3
Pull-Request: https://github.com/git/git/pull/808

Range-diff vs v2:

 1:  e266bc39d99 = 1:  e266bc39d99 wt-status: show sparse checkout status as well
 -:  ----------- > 2:  1fd1b919684 git-prompt: document how in-progress operations affect the prompt
 2:  17254b30a5b ! 3:  d99202f8e14 git-prompt: include sparsity state as well
     @@ Metadata
       ## Commit message ##
          git-prompt: include sparsity state as well
      
     -    The current git prompt includes a lot of possible state information from
     -    cherry-picks, merges, bisects, and various flavors of rebases.  Add
     -    sparsity as another state flavor (though one which can be present
     -    simultaneously with any of rebase/cherry-pick/merge/bisect).  This extra
     -    state is shown with an extra
     +    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
     -    substring before the other states, providing a prompt that looks like:
     +    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
     @@ Commit message
          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>
      
       ## contrib/completion/git-prompt.sh ##
     +@@
     + # revert, cherry-pick, or bisect, the prompt will include information
     + # related to the operation, often in the form "|<OPERATION-NAME>".
     + #
     ++# When the repository has a sparse-checkout, a notification of the form
     ++# "|SPARSE" will be included in the prompt.  This can be shortened to a
     ++# single '?' character by setting GIT_PS1_COMPRESSSPARSESTATE, or omitted
     ++# by setting GIT_PS1_OMITSPARSESTATE.
     ++#
     + # By default, __git_ps1 will compare HEAD to your SVN upstream if it can
     + # find one, or @{upstream} otherwise.  Once you have set
     + # GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by
      @@ contrib/completion/git-prompt.sh: __git_ps1 ()
       		return $exit
       	fi
       
      +	local sparse=""
     -+	if [ "$(git config --bool core.sparseCheckout)" == "true" ]; then
     -+	    sparse="|SPARSE"
     ++	if [ -z "${GIT_PS1_COMPRESSSPARSESTATE}" ] &&
     ++	   [ -z "${GIT_PS1_OMITSPARSESTATE}" ] &&
     ++	   [ "$(git config --bool core.sparseCheckout)" == "true" ]; then
     ++		sparse="|SPARSE"
      +	fi
      +
       	local r=""
       	local b=""
       	local step=""
      @@ contrib/completion/git-prompt.sh: __git_ps1 ()
     + 	local i=""
     + 	local s=""
     + 	local u=""
     ++	local h=""
     + 	local c=""
     + 	local p=""
     + 
     +@@ contrib/completion/git-prompt.sh: __git_ps1 ()
     + 			u="%${ZSH_VERSION+%}"
     + 		fi
     + 
     ++		if [ -n "${GIT_PS1_COMPRESSSPARSESTATE}" ] &&
     ++		   [ "$(git config --bool core.sparseCheckout)" == "true" ]; then
     ++			h="?"
     ++		fi
     ++
     + 		if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ]; then
     + 			__git_ps1_show_upstream
     + 		fi
     +@@ contrib/completion/git-prompt.sh: __git_ps1 ()
     + 		b="\${__git_ps1_branch_name}"
       	fi
       
     - 	local f="$w$i$s$u"
     +-	local f="$w$i$s$u"
      -	local gitstring="$c$b${f:+$z$f}$r$p"
     ++	local f="$h$w$i$s$u"
      +	local gitstring="$c$b${f:+$z$f}${sparse}$r$p"
       
       	if [ $pcmode = yes ]; then

-- 
gitgitgadget

[PATCH v3 1/3] wt-status: show sparse checkout status as well

[Elijah Newren via GitGitGadget]

From: Elijah Newren <newren@gmail.com>

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>
---
 wt-status.c | 41 +++++++++++++++++++++++++++++++++++++++++
 wt-status.h |  2 ++
 2 files changed, 43 insertions(+)

diff --git a/wt-status.c b/wt-status.c
index 98dfa6f73f9..c560cbe860a 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1484,6 +1484,18 @@ static void show_bisect_in_progress(struct wt_status *s,
 	wt_longstatus_print_trailer(s);
 }
 
+static void show_sparse_checkout_in_use(struct wt_status *s,
+					const char *color)
+{
+	if (s->state.sparse_checkout_percentage == SPARSE_CHECKOUT_DISABLED)
+		return;
+
+	status_printf_ln(s, color,
+			 _("You are in a sparse checkout with %d%% of tracked files present."),
+			 s->state.sparse_checkout_percentage);
+	wt_longstatus_print_trailer(s);
+}
+
 /*
  * Extract branch information from rebase/bisect
  */
@@ -1623,6 +1635,31 @@ int wt_status_check_bisect(const struct worktree *wt,
 	return 0;
 }
 
+static void wt_status_check_sparse_checkout(struct repository *r,
+					    struct wt_status_state *state)
+{
+	int skip_worktree = 0;
+	int i;
+
+	if (!core_apply_sparse_checkout || r->index->cache_nr == 0) {
+		/*
+		 * Don't compute percentage of checked out files if we
+		 * aren't in a sparse checkout or would get division by 0.
+		 */
+		state->sparse_checkout_percentage = SPARSE_CHECKOUT_DISABLED;
+		return;
+	}
+
+	for (i = 0; i < r->index->cache_nr; i++) {
+		struct cache_entry *ce = r->index->cache[i];
+		if (ce_skip_worktree(ce))
+			skip_worktree++;
+	}
+
+	state->sparse_checkout_percentage =
+		100 - (100 * skip_worktree)/r->index->cache_nr;
+}
+
 void wt_status_get_state(struct repository *r,
 			 struct wt_status_state *state,
 			 int get_detached_from)
@@ -1658,6 +1695,7 @@ void wt_status_get_state(struct repository *r,
 	}
 	if (get_detached_from)
 		wt_status_get_detached_from(r, state);
+	wt_status_check_sparse_checkout(r, state);
 }
 
 static void wt_longstatus_print_state(struct wt_status *s)
@@ -1681,6 +1719,9 @@ static void wt_longstatus_print_state(struct wt_status *s)
 		show_revert_in_progress(s, state_color);
 	if (state->bisect_in_progress)
 		show_bisect_in_progress(s, state_color);
+
+	if (state->sparse_checkout_percentage != SPARSE_CHECKOUT_DISABLED)
+		show_sparse_checkout_in_use(s, state_color);
 }
 
 static void wt_longstatus_print(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 73ab5d4da1c..f1fa0ec1a75 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -79,6 +79,7 @@ enum wt_status_format {
 
 #define HEAD_DETACHED_AT _("HEAD detached at ")
 #define HEAD_DETACHED_FROM _("HEAD detached from ")
+#define SPARSE_CHECKOUT_DISABLED -1
 
 struct wt_status_state {
 	int merge_in_progress;
@@ -90,6 +91,7 @@ struct wt_status_state {
 	int bisect_in_progress;
 	int revert_in_progress;
 	int detached_at;
+	int sparse_checkout_percentage; /* SPARSE_CHECKOUT_DISABLED if not sparse */
 	char *branch;
 	char *onto;
 	char *detached_from;
-- 
gitgitgadget

[PATCH v3 2/3] git-prompt: document how in-progress operations affect the prompt

[Elijah Newren via GitGitGadget]

From: Elijah Newren <newren@gmail.com>

Signed-off-by: Elijah Newren <newren@gmail.com>
---
 contrib/completion/git-prompt.sh | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 014cd7c3cfc..179b96e4936 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -70,6 +70,10 @@
 # state symbols by setting GIT_PS1_STATESEPARATOR. The default separator
 # is SP.
 #
+# When there is an in-progress operation such as a merge, rebase,
+# revert, cherry-pick, or bisect, the prompt will include information
+# related to the operation, often in the form "|<OPERATION-NAME>".
+#
 # By default, __git_ps1 will compare HEAD to your SVN upstream if it can
 # find one, or @{upstream} otherwise.  Once you have set
 # GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by
-- 
gitgitgadget

[PATCH v3 3/3] git-prompt: include sparsity state as well

[Elijah Newren via GitGitGadget]

From: Elijah Newren <newren@gmail.com>

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>
---
 contrib/completion/git-prompt.sh | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 179b96e4936..e6cd5464e5c 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -74,6 +74,11 @@
 # revert, cherry-pick, or bisect, the prompt will include information
 # related to the operation, often in the form "|<OPERATION-NAME>".
 #
+# When the repository has a sparse-checkout, a notification of the form
+# "|SPARSE" will be included in the prompt.  This can be shortened to a
+# single '?' character by setting GIT_PS1_COMPRESSSPARSESTATE, or omitted
+# by setting GIT_PS1_OMITSPARSESTATE.
+#
 # By default, __git_ps1 will compare HEAD to your SVN upstream if it can
 # find one, or @{upstream} otherwise.  Once you have set
 # GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by
@@ -425,6 +430,13 @@ __git_ps1 ()
 		return $exit
 	fi
 
+	local sparse=""
+	if [ -z "${GIT_PS1_COMPRESSSPARSESTATE}" ] &&
+	   [ -z "${GIT_PS1_OMITSPARSESTATE}" ] &&
+	   [ "$(git config --bool core.sparseCheckout)" == "true" ]; then
+		sparse="|SPARSE"
+	fi
+
 	local r=""
 	local b=""
 	local step=""
@@ -496,6 +508,7 @@ __git_ps1 ()
 	local i=""
 	local s=""
 	local u=""
+	local h=""
 	local c=""
 	local p=""
 
@@ -528,6 +541,11 @@ __git_ps1 ()
 			u="%${ZSH_VERSION+%}"
 		fi
 
+		if [ -n "${GIT_PS1_COMPRESSSPARSESTATE}" ] &&
+		   [ "$(git config --bool core.sparseCheckout)" == "true" ]; then
+			h="?"
+		fi
+
 		if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ]; then
 			__git_ps1_show_upstream
 		fi
@@ -546,8 +564,8 @@ __git_ps1 ()
 		b="\${__git_ps1_branch_name}"
 	fi
 
-	local f="$w$i$s$u"
-	local gitstring="$c$b${f:+$z$f}$r$p"
+	local f="$h$w$i$s$u"
+	local gitstring="$c$b${f:+$z$f}${sparse}$r$p"
 
 	if [ $pcmode = yes ]; then
 		if [ "${__git_printf_supports_v-}" != yes ]; then
-- 
gitgitgadget

Re: [PATCH v3 3/3] git-prompt: include sparsity state as well

[Junio C Hamano]

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Elijah Newren <newren@gmail.com>
> ...
> The reason for showing the "|SPARSE" substring before other states is to
> ...
> 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.

Nicely explained.  It somewhat feels a bit overkill to have two
(i.e. compress vs omit) knobs---the other "semi-permanent" state
that may be of interest but could become too noisy only have one
knob that toggles between showing a short-and-non-intrusive sign
and not showing anything at all with GIT_PS1_SHOWSTASHSTATE, and
that smells like a better balance to me, but I dunno.

Thanks.  Will queue.