On Sun, Mar 15, 2020 at 9:24 AM Derrick Stolee <stolee@xxxxxxxxx> wrote:
>
> On 3/14/2020 3:11 AM, Elijah Newren via GitGitGadget wrote:
> > From: Elijah Newren <newren@xxxxxxxxx>
> >
> > 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.
Makes sense; I'll switch it over to "reapply".
> > Signed-off-by: Elijah Newren <newren@xxxxxxxxx>
> > ---
> > 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?)
Good question. Is there a chance we want to make
update_working_directory() available to other areas of git outside of
sparse-checkout.c? If so, potentially re-reading the index might not
be friendly, but if sparse-checkout.c is going to remain the only
caller then it probably makes sense to move it inside.
> > 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);
> > }
