On Mon, Mar 21, 2022 at 11:34 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> "Neeraj Singh via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
> > From: Neeraj Singh <neerajsi@xxxxxxxxxxxxx>
> >
> > Add test cases to exercise batch mode for:
> > * 'git add'
>
> I was wondering why the obviously safe and good candidate 'git add' is
> not gaining plug/unplug pair in this series. It is obviously safe,
> unlike 'update-index', that nobody can interact with it, observe its
> intermediate output, and expect anything from it.
>
> I think the stupid reason of the lack of new plug/unplug is because
> we already had them, which is good ;-).
>
> > * 'git stash'
> > * 'git update-index'
>
> As I said, I suspect that we'd want to do this safely by adding a
> new option to "update-index" and passing it from "stash" which knows
> that it does not care about the intermediate state.
>
> > These tests ensure that the added data winds up in the object database.
>
> In other words, "git add $path; git rev-parse :$path" (and its
> cousins) would be happy? Like new object files not left hanging in
> a tentative object store etc. _after_ the commands finish.
>
> Good.
>
> > In this change we introduce a new test helper lib-unique-files.sh. The
> > goal of this library is to create a tree of files that have different
> > oids from any other files that may have been created in the current test
> > repo. This helps us avoid missing validation of an object being added due
> > to it already being in the repo.
>
> More on this below.
To me the idea of putting the 'why' into the commit message and the 'what' into
code comments makes sense, since I'd assume people looking into the history
care about the why, but people making future changes would read the
documentation
in the comments for e.g. lib-unique-files.
>
> > We aren't actually issuing any fsyncs in these tests, since
> > GIT_TEST_FSYNC is 0, but we still exercise all of the tmp_objdir logic
> > in bulk-checkin.
>
> Shouldn't we manually override that, if it matters?
> Not a suggestion but a question.
I manually override it for the performance tests. I think it's
sensible to manually override
this variable for the small number of tests added in this commit so
that we can exercise
the underlying system calls, so I'll do that.
> > +# Create multiple files with unique contents. Takes the number of
> > +# directories, the number of files in each directory, and the base
> > +# directory.
>
> This is more honest, compared to the claim made in the proposed log
> message, in that the uniqueness guarantee is only among the files
> created by this helper. If we created other test contents without
> using this helper, that may crash with the ones created here.
>
I've revised this comment to indicate that the files are only unique
within this test run.
> > +# test_create_unique_files 2 3 my_dir -- Creates 2 directories with 3 files
> > +# each in my_dir, all with unique
> > +# contents.
> > +
> > +test_create_unique_files() {
>
> Style. SP on both sides of (). I.e.
>
> test_create_unique_files () {
>
Fixed
> > + test "$#" -ne 3 && BUG "3 param"
> > +
> > + local dirs=$1
> > + local files=$2
> > + local basedir=$3
> > + local counter=0
> > + test_tick
> > + local basedata=$test_tick
>
> I am not sure if consumption and reliance on tick is a wise thing.
> $basedir must be unique across all the other directories in this
> test repository (there is no other $basedir)---can't we key
> uniqueness off of it?
In the performance tests, we create sets of files with the same basedir
but we want the files to have different contents since we don't blow away
the repo between tests. The current approach still generates uniqueness
if someone simply copy/pastes a test_create_unique_files invocation, rather
than subtly failing to make new objects.
> > + rm -rf $basedir
>
> Can $basedir have any $IFS character in it? We should "$quote" it.
Fixed.
>
> > + for i in $(test_seq $dirs)
> > + do
> > + local dir=$basedir/dir$i
> > +
> > + mkdir -p "$dir"
> > + for j in $(test_seq $files)
> > + do
> > + counter=$((counter + 1))
> > + echo "$basedata.$counter" >"$dir/file$j.txt"
>
> An extra SP before ">"?
>
Fixed.
> > + done
> > + done
> > +}
>
> There is no &&- cascade here, and we expect nothing in this to
> fail. Is that sensible?
>
I apologize, there's a lot of subtlety about UNIX shell scripting that
I simply do not know. I put an '&&' chain in, but I might still have it wrong.
> > +test_expect_success 'git add: core.fsyncmethod=batch' "
> > + test_create_unique_files 2 4 fsync-files &&
> > + git $BATCH_CONFIGURATION add -- ./fsync-files/ &&
> > + rm -f fsynced_files &&
> > + git ls-files --stage fsync-files/ > fsynced_files &&
>
> Style. No SP between redirection operator and its target. I.e.
>
> git ls-files --stage fsync-files/ >fsynced_files &&
>
> Mixture of names-with-dash and name_with_understore looks somewhat
> irritating.
>
Will switch to underscores for both. Also will rename the base dir to be more
distinct from the list of files that we expect to see.
> > + test_line_count = 8 fsynced_files &&
>
> The magic "8" matches "2 4" we saw earlier for create_unique_files?
>
Will comment to explain the 8.
> > + awk -- '{print \$2}' fsynced_files | xargs -n1 git cat-file -e
>
> A test helper that takes the name of a file that has "ls-files -s" output
> may prove to be useful. I dunno.
>
> > diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
> > index a11d61206ad..8e2f73cc68f 100755
> > --- a/t/t5300-pack-object.sh
> > +++ b/t/t5300-pack-object.sh
> > @@ -162,23 +162,25 @@ test_expect_success 'pack-objects with bogus arguments' '
> >
> > check_unpack () {
> > test_when_finished "rm -rf git2" &&
> > - git init --bare git2 &&
> > - git -C git2 unpack-objects -n <"$1".pack &&
> > - git -C git2 unpack-objects <"$1".pack &&
> > - (cd .git && find objects -type f -print) |
> > - while read path
> > - do
> > - cmp git2/$path .git/$path || {
> > - echo $path differs.
> > - return 1
> > - }
> > - done
> > + git $2 init --bare git2 &&
> > + (
> > + git $2 -C git2 unpack-objects -n <"$1".pack &&
> > + git $2 -C git2 unpack-objects <"$1".pack &&
> > + git $2 -C git2 cat-file --batch-check="%(objectname)"
> > + ) <obj-list >current &&
> > + cmp obj-list current
> > }
>
> I think the change from the old "the existence and the contents of
> the object files must all match" to the new "cat-file should say
> that the objects we expect to exist indeed do" is not a bad thing.
>
> We used to only depend on the contents of the provided packfile but
> now we assume that obj-list file gives us the list of objects. Is
> that sensible? I somehow do not think so. Don't we have the
> corresponding "$1.idx" that we can feed to "git show-index", e.g.
>
I believe that "obj-list" is in some sense more authoritative,
assuming arbitrary
future bugs in the pack implementation. We make sure that the pack we were
handed isn't missing any objects. It makes sense to accept obj-list from
the outside so that check_unpack itself doesn't depend on that file name.
But the previous code wouldn't catch a bug where the pack code mistakenly drops
an object.
> git show-index <"$1.pack" >expect.full &&
> cut -d" " -f2 >expect <expect.full &&
> ... your test in "$2", but feeding expect instead of obj-list ...
> test_cmp expect actual
>
> Also make sure you quote whatever is coming from outside, even if
> you happen to call the helper with tokens that do not need quoting
> in the current code. It is a good discipline to help readers.
>
> Thanks.
I'll take another pass over the shell code in the morning to make sure
I'm following all the conventions and recommendations. Apologize
for the set of mistakes. In terms of shell, I am a rookie.
Thanks,
-Neeraj
