git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
From: Yaroslav O Halchenko <debian@onerussian.com>
To: git <git@vger.kernel.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 23:22:05 -0500
Message-ID: <20181214042205.GJ4633@hopa.kiewit.dartmouth.edu> (raw)
In-Reply-To: <CAGZ79kaLpMa+AYwtNh+HUkYk3ORDephxZ74hcTbS=z1CQ+bf6A@mail.gmail.com>


On Thu, 13 Dec 2018, Stefan Beller wrote:

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

oh, by replicate I just meant to copy/paste and adjust for expected for
--reset-hard test behavior (and possibly introduced helper),
nothing fancy, just duplication as for replication ;-) 

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

ok

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

no, not really any good ideas -- I am new here, but I will keep an eye open.

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

wouldn't it be (theoretically) possible, in principle, to pass
them via some config variable?  e.g. instead of  

submodule update --reset-hard

have

-c submodule.update.reset.opts=--hard update --reset

and then analogously

-c submodule.update.merge.opts=--ff-only update --merge

(--ff-only I guess would make no sense for any "supermodule" - a repo
with submodules)

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

that is a good idea as a workaround, thanks!

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

      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
2018-12-14  4:22                               ` Yaroslav O Halchenko [this message]

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=20181214042205.GJ4633@hopa.kiewit.dartmouth.edu \
    --to=debian@onerussian.com \
    --cc=git@vger.kernel.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

git@vger.kernel.org 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