Re: [PATCH v4 1/7] t7063: more thorough status checking

[Elijah Newren <newren@gmail.com>]

On Sun, Mar 29, 2020 at 11:18 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Derrick Stolee <stolee@gmail.com> writes:
>
> >> +# Ignore_Untracked_Cache, abbreviated to 3 letters because then people can
> >> +# compare commands side-by-side, e.g.
> >> +#    iuc status --porcelain >expect &&
> >> +#    git status --porcelain >actual &&
> >> +#    test_cmp expect actual
>
> ;-)
>
> >> +iuc() {
>
> Missing SP after "iuc".

Will fix.

> >> +    git ls-files -s >../current-index-entries
> >> +    git ls-files -t | grep ^S | sed -e s/^S.// >../current-sparse-entries
>
> When you see yourself piping grep output to sed, think twice to see
> if you can lose one of them.  sed -ne 's/^S.//p' perhaps?

Ooh, thanks.  I have to admit that I don't know sed very well.  In
fact, 'sed -e s/pattern/replacement/' was the _only_ piece of sed I
knew.  But the -n flag and p modifier look handy; I think I ran across
them in perl before as well.

> >> +
> >> +    GIT_INDEX_FILE=.git/tmp_index
> >> +    export GIT_INDEX_FILE
> >> +    git update-index --index-info <../current-index-entries
> >> +    git update-index --skip-worktree $(cat ../current-sparse-entries)
>
> Are the dances with ls-files and update-index to prepare us for a
> possible future in which we do not use .git/index as the index file,
> or something?  IOW, would
>
>         export GIT_INDEX_FILE=.git/tmp_index &&
>         cp .git/index "$GIT_INDEX_FILE &&
>
> be insufficient?

I guess it's a matter of perspective.  Do we want to compare to how
git behaves when there is no untracked cache (as I was trying to
implement), or compare to how git behaves when there is an untracked
cache and git is told to remove it?  (The documentation for
core.untrackedCache doesn't actually say when
core.untrackedCache=false that git will ignore it, just that it will
delete the untracked cache when that option is set.  Perhaps if we do
go the route with your alternative, we at least need to update the
documentation as well and perhaps also audit the code to make sure it
ignores the untracked cache as I'd expect?  Or maybe we just need to
run two operations, one to delete the untracked cache, and then the
second that we are actually comparing to?)

> >> +
> >> +    git -c core.untrackedCache=false "$@"
> >> +    ret=$?
> >> +
> >> +    rm ../current-index-entries
> >> +    rm $GIT_INDEX_FILE
> >> +    unset GIT_INDEX_FILE
> >> +
> >> +    return $ret
> >> +}
> >
> > This is a clever way to get around the untracked cache deletion.
> >
> > Thanks for adding these extra comparisons! It really does help guarantee
> > that we are doing the right thing in each case.
>
> Yes, I think it is a great idea to see tested commands behave the
> same way with or without the untracked cache.

Thanks.