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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 18, 2020 at 2:46 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> "Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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?



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux