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) There is no easy way to parametrize them somehow?
;) 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.
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.
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.
--
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
