git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v6 09/10] submodule: support reading .gitmodules when it's not in the working tree

From
Antonio Ospite <ao2@ao2.it>
Date
Oct 10, 2018, 18:56 UTC
Message-ID
<20181010205645.e1529eff9099805029b1d6ef@ao2.it>
In-Reply-To
<CAGZ79kZTQB29SuB52Efk-j7jX11BRU_RFiX+znttvP2tFRaNvg@mail.gmail.com>

On Mon, 8 Oct 2018 15:19:00 -0700 Stefan Beller <sbeller@google.com> wrote:

Show 7 quoted lines
> > +test_expect_success 'not writing gitmodules config file when it is not checked out' '
> > +        test_must_fail git -C super submodule--helper config submodule.submodule.url newurl
> 
> This only checks the exit code, do we also want to check for
> 
>     test_path_is_missing .gitmodules ?
>

OK, I agree, let's re-check also *after* we tried and failed to set a config value, just to be sure that the code does not get accidentally changed in the future to create the file. I'll add the check.

Show 11 quoted lines
> > +test_expect_success 'initialising submodule when the gitmodules config is not checked out' '
> > +       git -C super submodule init
> > +'
> > +
> > +test_expect_success 'showing submodule summary when the gitmodules config is not checked out' '
> > +       git -C super submodule summary
> > +'
> 
> Same for these, is the exit code enough, or do we want to look at
> specific things?
>

Except for the "summary" test which was not even exercising the config_from_gitmodule path, checking exist status should be sufficient to verify that "submodule--helper config" does not fail, but we can surely do better.

I will add checks to confirm that not only the commands exited without errors but they also achieved the desired effect, to validate the actual high-level use case advertised by the test file. This should be more future-proof.

And I think I'll merge the summary and the update tests.
Show 10 quoted lines
> > +
> > +test_expect_success 'updating submodule when the gitmodules config is not checked out' '
> > +       (cd submodule &&
> > +               echo file2 >file2 &&
> > +               git add file2 &&
> > +               git commit -m "add file2 to submodule"
> > +       ) &&
> > +       git -C super submodule update
> 
> git status would want to be clean afterwards?

Mmh, this should have been "submodule update --remote" in the first place to have any effect, I'll take the chance and rewrite this test in a different way and also check the effect of the update operation, and the repository status.

I'll be something like this:

ORIG_SUBMODULE=$(git -C submodule rev-parse HEAD) ORIG_UPSTREAM=$(git -C upstream rev-parse HEAD) ORIG_SUPER=$(git -C super rev-parse HEAD)

test_expect_success 're-updating submodule when the gitmodules config is not checked out' '
	test_when_finished "git -C submodule reset --hard $ORIG_SUBMODULE;
	                    git -C upstream reset --hard $ORIG_UPSTREAM;
	                    git -C super reset --hard $ORIG_SUPER;
	                    git -C upstream submodule update --remote;
	                    git -C super pull;
	                    git -C super submodule update --remote" &&
	(cd submodule &&
		echo file2 >file2 &&
		git add file2 &&
		test_tick &&
		git commit -m "add file2 to submodule"
	) &&
	(cd upstream &&
		git submodule update --remote &&
		git add submodule &&
		test_tick &&
		git commit -m "Update submodule"
	) &&
	git -C super pull &&
	# The --for-status options reads the gitmdoules config
	git -C super submodule summary --for-status >actual &&
	cat >expect <<-\EOF &&
	* submodule 951c301...a939200 (1):
	  < add file2 to submodule
	
	EOF
	test_cmp expect actual &&
	# Test that the update actually succeeds
	test_path_is_missing super/submodule/file2 &&
	git -C super submodule update &&
	test_cmp submodule/file2 super/submodule/file2 &&
	git -C super status --short >output &&
	test_must_be_empty output
'
Maybe a little overkill?

The "upstream" repo will be added in test 1 to better clarify the roles of the involved repositories.

The commit ids should be stable because of test_tick, shouldn't they?

Thanks for the comments, they helped improving the quality of the tests once again.

I'll wait a few days before sending a v7, hopefully someone will find time to take another look at patch 9 and comment also on patch 10, and give an opinion on the "mergeability" status of the whole patchset.

Ciao ciao,
   Antonio
-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
Previous: Stefan BellerNext: Stefan Beller
Message 5 of 23 in “Make submodules work if .gitmodules is not checked out”
  1. 00/10 Make submodules work if .gitmodules is not checked outAntonio Ospite, Oct 5, 2018
  2. 03/10 t7411: merge tests 5 and 6Antonio Ospite, Oct 5, 2018
  3. 09/10 submodule: support reading .gitmodules when it's not in the working treeAntonio Ospite, Oct 5, 2018
  4. Stefan BellerOct 8, 2018
  5. Antonio OspiteOct 10, 2018
  6. Stefan BellerOct 10, 2018
  7. Junio C HamanoOct 9, 2018
  8. Junio C HamanoOct 9, 2018
  9. 04/10 t7411: be nicer to future tests and really clean things upAntonio Ospite, Oct 5, 2018
  10. 10/10 t/helper: add test-submodule-nested-repo-configAntonio Ospite, Oct 5, 2018
  11. 02/10 submodule: factor out a config_set_in_gitmodules_file_gently functionAntonio Ospite, Oct 5, 2018
  12. 01/10 submodule: add a print_config_from_gitmodules() helperAntonio Ospite, Oct 5, 2018
  13. 06/10 submodule: use the 'submodule--helper config' commandAntonio Ospite, Oct 5, 2018
  14. 05/10 submodule--helper: add a new 'config' subcommandAntonio Ospite, Oct 5, 2018
  15. 08/10 submodule: add a helper to check if it is safe to write to .gitmodulesAntonio Ospite, Oct 5, 2018
  16. Stefan BellerOct 5, 2018
  17. Antonio OspiteOct 6, 2018
  18. Junio C HamanoOct 6, 2018
  19. Antonio OspiteOct 8, 2018
  20. 07/10 t7506: clean up .gitmodules properly before setting up new scenarioAntonio Ospite, Oct 5, 2018
  21. Antonio OspiteOct 6, 2018
  22. Junio C HamanoOct 25, 2018
  23. Antonio OspiteOct 25, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.