list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Stefan Beller <>
Cc: git <>
Subject: Re: [PATCH 2/2] RF+ENH(TST): compare the entire list of submodule status --recursive to stay intact
Date: Thu, 13 Dec 2018 15:58:51 -0800
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Dec 13, 2018 at 2:44 PM Yaroslav O Halchenko
<> wrote:
> 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/, 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.

> ;)    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.

> 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:  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?

  reply	other threads:[~2018-12-14  0:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06 17:35 [wishlist] git submodule update --reset-hard Yaroslav Halchenko
2018-12-06 18:29 ` Stefan Beller
2018-12-06 21:24   ` Yaroslav Halchenko
2018-12-06 21:55     ` Stefan Beller
2018-12-07  1:22       ` Yaroslav Halchenko
2018-12-07 21:55         ` Stefan Beller
2018-12-08  2:15           ` Yaroslav Halchenko
2018-12-08  4:21             ` Yaroslav Halchenko
2018-12-10 18:58               ` Stefan Beller
2018-12-10 20:14                 ` Yaroslav Halchenko
2018-12-11  4:08                 ` [PATCH 1/2] submodule: Add --reset-hard option for git submodule update Yaroslav Halchenko
2018-12-11  4:08                   ` [PATCH 2/2] RF+ENH(TST): compare the entire list of submodule status --recursive to stay intact Yaroslav Halchenko
2018-12-12 19:48                     ` Stefan Beller
2018-12-13 16:42                       ` Yaroslav O Halchenko
2018-12-13 20:44                         ` Stefan Beller
2018-12-13 22:43                           ` Yaroslav O Halchenko
2018-12-13 23:58                             ` Stefan Beller [this message]
2018-12-14  4:22                               ` Yaroslav O Halchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

code repositories for the project(s) associated with this inbox:

AGPL code for this site: git clone