From: Stefan Beller <firstname.lastname@example.org> To: email@example.com Cc: git <firstname.lastname@example.org> 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: <CAGZ79kaLpMa+AYwtNh+HUkYk3ORDephxZ74hcTbS=z1CQ+bf6A@mail.gmail.com> (raw) In-Reply-To: <20181213224356.GI4633@hopa.kiewit.dartmouth.edu> On Thu, Dec 13, 2018 at 2:44 PM Yaroslav O Halchenko <email@example.com> 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/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. > ;) 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: 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?
next prev parent reply index 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 publically 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAGZ79kaLpMa+AYwtNh+HUkYk3ORDephxZ74hcTbS=z1CQ+bf6A@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
email@example.com list mirror (unofficial, one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox