On Wed, Mar 17, 2021 at 2:36 PM Elijah Newren <newren@xxxxxxxxx> wrote:
>
> On Tue, Mar 16, 2021 at 2:17 PM Derrick Stolee via GitGitGadget
> <gitgitgadget@xxxxxxxxx> wrote:
> >
> > From: Derrick Stolee <dstolee@xxxxxxxxxxxxx>
> >
> > Before iterating over all cache entries, ensure that a sparse index is
> > expanded to a full index to avoid unexpected behavior.
> >
> > Signed-off-by: Derrick Stolee <dstolee@xxxxxxxxxxxxx>
> > ---
> > builtin/add.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/builtin/add.c b/builtin/add.c
> > index ea762a41e3a2..ab2ef4a63530 100644
> > --- a/builtin/add.c
> > +++ b/builtin/add.c
> > @@ -141,6 +141,7 @@ static int renormalize_tracked_files(const struct pathspec *pathspec, int flags)
> > {
> > int i, retval = 0;
> >
> > + ensure_full_index(&the_index);
> > for (i = 0; i < active_nr; i++) {
> > struct cache_entry *ce = active_cache[i];
>
> I'm not so sure about this one; from git-add(1):
>
> --renormalize
> Apply the "clean" process freshly to all tracked files to forcibly
> add them again to the index. This is useful after changing
> core.autocrlf configuration or the text attribute in order to
> correct files added with wrong CRLF/LF line endings. This option
> implies -u.
>
> ... to "all tracked files". Should that be interpreted as all files
> within the sparsity paths, especially considering that we're trying to
> enable folks to work within the set of files of interest to them?
I had the same question when working on the add/rm sparse-checkout
series. As seen at [1], --renormalize and --chmod are, currently, the
only options in git-add that do not honor the sparsity patterns and do
update SKIP_WORKTREE paths too.
But is this by design or possibly just an oversight? In my series I
ended up making both options honor the sparsity rules, with a warning
when requested to update any sparse path. (If we are going with this
approach, perhaps should we also amend the docs to remove any
ambiguity as for what "all tracked files" means in this case?)
> The code below already has the following check below:
>
> if (!S_ISREG(ce->ce_mode) && !S_ISLNK(ce->ce_mode))
> continue; /* do not touch non blobs */
>
> suggesting that it'd correctly skip over the sparse directories, so I
> think this one just isn't needed.
But if sparse index is not enabled, it does not skip over the sparse
files, right? So isn't the ensure_full_index() call here (and in
chmod_pathspec()) important to be consistent with the case when sparse
index is not in use? Or maybe Stolee could rebase this on top of my
series, where both these places already skip the sparse paths?
(Assuming that's the behavior we are looking for. If not, I can also
fix my series.)
[1]: https://lore.kernel.org/git/d93c3f51465a3e409819db63bd81802e7ef20ea9.1615588108.git.matheus.bernardino@xxxxxx/
