Re: [PATCH 7/7] sparse-checkout: provide a new update subcommand

>
> On 3/14/2020 3:11 AM, Elijah Newren via GitGitGadget wrote:
> > From: Elijah Newren <newren@gmail.com>
> >
> > If commands like merge or rebase materialize files as part of their work,
> > or a previous sparse-checkout command failed to update individual files
> > due to dirty changes, users may want a command to simply 'reapply' the
> > sparsity rules.  Provide one.
>
> I was actually thinking "refresh" would be a better name, but also you
> use "reapply" which is good, too. I'm concerned that "update" may imply
> that the sparse-checkout patterns can change, but you really mean to
> re-do the work from a previous "git sparse-checkout (set|add)".
>
> I also thought of "reset" but that would be a confusing overload.

> > Signed-off-by: Elijah Newren <newren@gmail.com>
> > ---
> >  Documentation/git-sparse-checkout.txt | 10 ++++++++++
> >  builtin/sparse-checkout.c             | 10 +++++++++-
> >  2 files changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/git-sparse-checkout.txt b/Documentation/git-sparse-checkout.txt
> > index c0342e53938..27f4392489f 100644
> > --- a/Documentation/git-sparse-checkout.txt
> > +++ b/Documentation/git-sparse-checkout.txt
> > @@ -70,6 +70,16 @@ C-style quoted strings.
> >       `core.sparseCheckoutCone` is enabled, the given patterns are interpreted
> >       as directory names as in the 'set' subcommand.
> >
> > +'update'::
> > +     Update the sparseness of paths in the working tree based on the
> > +     existing patterns.  Commands like merge or rebase can materialize
> > +     paths to do their work (e.g. in order to show you a conflict), and
> > +     other sparse-checkout commands might fail to sparsify an individual
> > +     file (e.g. because it has unstaged changes or conflicts).  In such
> > +     cases, it can make sense to run `git sparse-checkout update` later
> > +     after cleaning up affected paths (e.g. resolving conflicts, undoing
> > +     or committing changes, etc.).
> > +
> >  'disable'::
> >       Disable the `core.sparseCheckout` config setting, and restore the
> >       working directory to include all files. Leaves the sparse-checkout
> > diff --git a/builtin/sparse-checkout.c b/builtin/sparse-checkout.c
> > index 5d3ec2e6be9..2ae21011dfd 100644
> > --- a/builtin/sparse-checkout.c
> > +++ b/builtin/sparse-checkout.c
> > @@ -18,7 +18,7 @@
> >  static const char *empty_base = "";
> >
> >  static char const * const builtin_sparse_checkout_usage[] = {
> > -     N_("git sparse-checkout (init|list|set|add|disable) <options>"),
> > +     N_("git sparse-checkout (init|list|set|add|update|disable) <options>"),
> >       NULL
> >  };
> >
> > @@ -552,6 +552,12 @@ static int sparse_checkout_set(int argc, const char **argv, const char *prefix,
> >       return modify_pattern_list(argc, argv, m);
> >  }
> >
> > +static int sparse_checkout_update(int argc, const char **argv)
> > +{
> > +     repo_read_index(the_repository);
> > +     return update_working_directory(NULL);
> > +}
> > +
>
> Short and sweet! I suppose my earlier comment about whether
> repo_read_index() was necessary is answered here. Perhaps it
> should be part of update_working_directory()? (And pass a
> repository pointer to it?)

> >  static int sparse_checkout_disable(int argc, const char **argv)
> >  {
> >       struct pattern_list pl;
> > @@ -601,6 +607,8 @@ int cmd_sparse_checkout(int argc, const char **argv, const char *prefix)
> >                       return sparse_checkout_set(argc, argv, prefix, REPLACE);
> >               if (!strcmp(argv[0], "add"))
> >                       return sparse_checkout_set(argc, argv, prefix, ADD);
> > +             if (!strcmp(argv[0], "update"))
> > +                     return sparse_checkout_update(argc, argv);
> >               if (!strcmp(argv[0], "disable"))
> >                       return sparse_checkout_disable(argc, argv);
> >       }