Re: [PATCH 2/2] RF+ENH(TST): compare the entire list of submodule status --recursive to stay intact

From: Stefan Beller <sbeller@google.com>
Date: Dec 13, 2018, 23:58 UTC
Message-ID: <CAGZ79kaLpMa+AYwtNh+HUkYk3ORDephxZ74hcTbS=z1CQ+bf6A@mail.gmail.com>
In-Reply-To: <20181213224356.GI4633@hopa.kiewit.dartmouth.edu>

On Thu, Dec 13, 2018 at 2:44 PM Yaroslav O Halchenko <debian@onerussian.com> wrote:

Show 20 quoted lines

>
>
> On Thu, 13 Dec 2018, Stefan Beller wrote:
>
> > > and kaboom -- we have a new test.  If we decide to test more -- just tune up
> > > test_expect_unchanged_submodule_status and done -- all the tests remain
> > > sufficiently prescribed.
>
> > > What do you think?
>
> > That is pretty cool. Maybe my gut reaction on the previous patch
> > also had to do with the numbers, i.e. having 2 extra function for
> > only having 2 tests more legible. A framework is definitely better
> > once we have more tests.
>
> cool, thanks for the feedback - I will then try to make it happen
>
> quick one (so when I get to it I know):  should I replicate all those
> tests you have for other update strategies? (treating of config
> specifications etc)

If there is a sensible way to do so? I have the impression that there are enough differences, that it may not be possible to replicate all tests meaningfully from the other modes.

> There is no easy way to parametrize them somehow?

There is t/lib-submodule-update.sh, which brings this to an extreme, as it makes a "test suite in a test suite"; and I would not follow that example for this change.

Show 5 quoted lines

> ;)    In Python world I might have mocked the actual underlying call to
> update, to see what option it would be getting and assure that it is the
> one I specified via config, and then sweepped through all of them
> to make sure nothing interim changes it.  Just wondering if may be
> something like that exists in git's tests support.

gits tests are very heavy on end to end testing, i.e. run a whole command and observe its output. This makes our command setup code, (i.e. finding the repository, parsing options, reading possible config, etc) a really well exercised code path. ;-)

There is a recent push towards testing only units, most of t/helper is used for that, e.g. c.f. 4c7bb45269 (test-reach: test get_reachable_subset, 2018-11-02).

So if you have a good idea how to focus the submodule tests more on the (new) unit that you add, that would be cool.

Show 7 quoted lines

> BTW - sorry if RTFM and unrelated, is there  a way to
>
>     update --merge
>
> but allowing only  fast-forwards?  My use case is collection of this
> submodules: http://datasets.datalad.org/?dir=/openneuro  which all
> should come from github and I should not have any changes of my own.

So you want the merge option --ff-only to be passed to the submodule merge command. I guess you could make a patch, that update takes another option (--ff-only, only useful when --merge is given), which is then propagated.

I am not sure if we could have a more generalized option passing, which would allow to pass any option (for its respective command) to the command that is run in the update mode.

> Sure thing if all is clean etc, merge should result in fast-forward.  I
> just do not want to miss a case where there was some (temporary?) "dirt"
> which I forgot to reset and it would then get merged etc.

maybe use --rebase, such that your potential change would bubble up and possibly produce a merge conflict?