From: Antonio Ospite <email@example.com>
To: Stefan Beller <firstname.lastname@example.org>
Cc: git <email@example.com>, "Brandon Williams" <firstname.lastname@example.org>,
"Daniel Graña" <email@example.com>,
"Jonathan Nieder" <firstname.lastname@example.org>,
"Richard Hartmann" <email@example.com>
Subject: Re: [RFC PATCH v2 10/12] t7416: add new test about HEAD:.gitmodules and not existing .gitmodules
Date: Thu, 9 Aug 2018 11:14:08 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On Thu, 2 Aug 2018 13:43:05 -0700
Stefan Beller <email@example.com> wrote:
> On Thu, Aug 2, 2018 at 6:47 AM Antonio Ospite <firstname.lastname@example.org> wrote:
> > git submodule commands can now access .gitmodules from the current
> > branch even when it's not in the working tree, add some tests for that
> > scenario.
> > Signed-off-by: Antonio Ospite <email@example.com>
> > ---
> > +NOTE: "git mv" and "git rm" are still supposed to work even without
> > +a .gitmodules file, as stated in the t3600-rm.sh and t7001-mv.sh tests.
> "supposed to work" != "tested that it works" ?
"git mv submod new_submod" and "git rm submod" are actually expected to
work without the .gitmodules file, and there are tests about that in
t3600-rm.sh and t7001-mv.sh:
'rm does not complain when no .gitmodules file is found'
'git mv moves a submodule with a .git directory and no .gitmodules'
'mv does not complain when no .gitmodules file is found'
> I am not sure what the NOTE wants to tell me? (Should I review those
> tests to double check them now? or do we just want to tell future readers
> of this test there are other tangent tests to this?)
Admittedly the NOTE is not useful without any context: during the
development of "submodule--helper config --stage" I initially assumed
that "git mv" and "git rm" should fail if .gitmodules was not available,
because these commands modify .gitmodules and I added code for that in
But then later I found out that my assumption was wrong and that git has
tests to verify that these operations on submodules succeed even when
.gitmodules does not exist, which was a little of a surprise to me.
So I removed all my code that was conflicting with git assumptions, and
added the NOTE. However I guess that was primarily a note to myself, and
it should have not slipped in the public patches.
I think I will remove the note, it can be confusing and does not really
add anything, and even less considering that "submodule--helper config
--stage" is going to be dropped.
> > +test_expect_success 'not adding submodules when the gitmodules config is not checked out' '
> > + (cd super &&
> > + test_must_fail git submodule add ../new_submodule
> > + )
> > +'
> > +
> > +# "git add" in the test above fails as expected, however it still leaves the
> > +# cloned tree in there and adds a config entry to .git/config. This is because
> > +# no cleanup is done by cmd_add in git-submodule.sh when "git
> > +# submodule--helper config" fails to add a new config setting.
> > +#
> > +# If we added the following commands to the test above:
> > +#
> > +# rm -rf .git/modules/new_submodule &&
> > +# git reset HEAD new_submodule &&
> > +# rm -rf new_submodule
> Alternatively we could check for the existence of .gitmodules
> before starting all these things?
You mean in cmd_add(), before doing anything?
The following would anticipates the same check which makes "git submodule
diff --git a/git-submodule.sh b/git-submodule.sh
index ff258e2e8c..b261175143 100755
@@ -159,6 +159,11 @@ cmd_add()
+ if test ! -e .gitmodules && git cat-file -e HEAD:.gitmodules
+ die "$(eval_gettext "please make sure that the .gitmodules file in the current branch is checked out")"
if test -n "$reference_path"
is_absolute_path "$reference_path" ||
This refers to .gitmodules explicitly but we said that we do not care
about that for now, if opaque access was ever needed in the future,
something like "submodule--helper config --is-writeable" could be added.
> I think it is okay to not clean up if we check all "regular" or rather expected
> things such as a non-writable .gitmodules file before actually doing it.
> (This is similar to 'checkout' that walks the whole tree and checks if the
> checkout is possible given the dirtyness of the tree, to either abort early
> or pull through completely. In catastrophic problems such as a full disk
> we'd still die in the middle of work)
> > +#
> > +# then the repository would be in a clean state and the test below would pass.
> > +#
> > +# Maybe cmd_add should do the cleanup from above itself when failing to add
> > +# a submodule.
> > +test_expect_failure 'init submodule after adding failed when the gitmodules config is not checked out' '
> So this comment and test is about explaining why we can fail mid way through,
> which we could not before unless we had the catastrophic event.
> I think we should check for a "writable" .gitmodules file at the beginning,
> which is if (G || (!G && !H)) [using the notation from the cover letter]?
> > + (cd super &&
> > + git submodule init
With the change from above this last test passes.
BTW the check I am using here and in the code of submodule--helper,
corresponds indeed to the boolean expression you mentioned, but
simplified and negated.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
next prev parent reply other threads:[~2018-08-09 9:14 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-02 13:46 [RFC PATCH v2 00/12] Make submodules work if .gitmodules is not checked out Antonio Ospite
2018-08-02 13:46 ` [RFC PATCH v2 01/12] submodule: add a print_config_from_gitmodules() helper Antonio Ospite
2018-08-02 18:05 ` Stefan Beller
2018-08-09 10:17 ` Antonio Ospite
2018-08-02 13:46 ` [RFC PATCH v2 02/12] submodule: factor out a config_set_in_gitmodules_file_gently function Antonio Ospite
2018-08-02 13:46 ` [RFC PATCH v2 03/12] t7411: be nicer to future tests and really clean things up Antonio Ospite
2018-08-02 16:40 ` SZEDER Gábor
2018-08-02 18:15 ` Stefan Beller
2018-08-09 13:59 ` Antonio Ospite
2018-08-02 18:44 ` Junio C Hamano
2018-08-02 13:46 ` [RFC PATCH v2 04/12] submodule--helper: add a new 'config' subcommand Antonio Ospite
2018-08-02 18:47 ` Stefan Beller
2018-08-02 19:20 ` Jeff King
2018-08-03 10:21 ` Antonio Ospite
2018-08-02 13:46 ` [RFC PATCH v2 05/12] submodule: use the 'submodule--helper config' command Antonio Ospite
2018-08-02 18:59 ` Stefan Beller
2018-08-02 13:46 ` [RFC PATCH v2 06/12] submodule--helper: add a '--stage' option to the 'config' sub command Antonio Ospite
2018-08-02 18:57 ` Junio C Hamano
2018-08-03 11:03 ` Antonio Ospite
2018-08-03 16:24 ` Junio C Hamano
2018-08-06 10:58 ` Antonio Ospite
2018-08-06 17:38 ` Junio C Hamano
2018-08-07 9:19 ` Antonio Ospite
2018-08-06 18:19 ` Stefan Beller
2018-08-02 13:46 ` [RFC PATCH v2 07/12] submodule: use 'submodule--helper config --stage' to stage .gitmodules Antonio Ospite
2018-08-02 13:46 ` [RFC PATCH v2 08/12] t7506: cleanup .gitmodules properly before setting up new scenario Antonio Ospite
2018-08-02 19:11 ` Stefan Beller
2018-08-02 13:46 ` [RFC PATCH v2 09/12] submodule: support reading .gitmodules even when it's not checked out Antonio Ospite
2018-08-02 20:27 ` Stefan Beller
2018-08-02 13:46 ` [RFC PATCH v2 10/12] t7416: add new test about HEAD:.gitmodules and not existing .gitmodules Antonio Ospite
2018-08-02 20:43 ` Stefan Beller
2018-08-09 9:14 ` Antonio Ospite [this message]
2018-08-02 13:46 ` [RFC PATCH v2 11/12] dir: move is_empty_file() from builtin/am.c to dir.c and make it public Antonio Ospite
2018-08-02 20:50 ` Stefan Beller
2018-08-03 8:49 ` Antonio Ospite
2018-08-02 13:46 ` [RFC PATCH v2 12/12] submodule: remove the .gitmodules file when it is empty Antonio Ospite
2018-08-02 21:15 ` Stefan Beller
2018-08-03 8:57 ` Antonio Ospite
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: 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 \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).