From: Heiko Voigt <hvoigt@hvoigt.net>
To: Charlie Dyson <charlie@charliedyson.net>
Cc: git@vger.kernel.org, Jens Lehmann <jens.lehmann@web.de>
Subject: Re: git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules
Date: Mon, 9 Dec 2013 23:35:06 +0100 [thread overview]
Message-ID: <20131209223506.GF9606@sandbox-ub> (raw)
In-Reply-To: <CABYr9QtSeX=Euf73MZPq6suo+GpVA=f+tH73Ct0tP-3LYogh9w@mail.gmail.com>
On Fri, Dec 06, 2013 at 03:48:46PM +0000, Charlie Dyson wrote:
> gitmodules(5) states that submodule.$name.update should be defined in
> .gitmodules. However in cmd_update() in git-submodule.sh, git config
> is used with "-f .gitmodules". Consequently this flag is only
> respected in .git/config
>
> Tested against: 1.8.2.1 [sorry! I've checked the relevant bit of
> source and it's the same]
>
> Steps to reproduce:
> $ git init
> $ git submodule add -b master someproject
> $ git config -f .gitmodules --add submodule.someproject.update merge
> $ # Go to someproject and commit something
> $ git submodule update --remote
>
> The latter does not perform a merge, and behaviour is visibly
> different to adding --merge.
This is because of histerical reasons. When submodules were first
implemented the notion was that .gitmodules should only be used as a
starting point to initialise the configuration in .git/config when init
was called.
This notion has changed in a way that only the url (by that the name)
should be copied on init. The default for everything else should come
from .gitmodules or gits own default.
The update configuration option was implemented before we realized that.
So currently it is still copied when submodule init is called. The main
reason is that we have not found the time to change that.
> I would submit a patch but I'm not completely sure what the behaviour
> would be - simply adding "-f .gitmodules" would hurt users that have
> adopted the practice of specifying their update preference in
> .git/config.
Well .gitmodules should only be the fallback if there is nothing in
.git/config.
> Perhaps the right thing to do is read from .git/config and fall back
> to .gitmodules using get_submodule_config().
Yes IMO that is the right thing to do. If you implement it that way (and
remove the automatic copying on init) you should not break peoples
expectations. So if you want to go ahead please send a patch.
Cheers Heiko
next prev parent reply other threads:[~2013-12-09 22:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 15:48 git-submodule.sh respects submodule.$name.update in .git/config but not .gitmodules Charlie Dyson
2013-12-09 22:35 ` Heiko Voigt [this message]
2013-12-09 23:40 ` Junio C Hamano
2013-12-11 22:26 ` Jens Lehmann
2013-12-11 22:44 ` W. Trevor King
2013-12-12 1:16 ` Junio C Hamano
2013-12-12 18:57 ` Jens Lehmann
2013-12-12 19:14 ` W. Trevor King
2013-12-12 19:23 ` Jonathan Nieder
2013-12-12 21:17 ` Junio C Hamano
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131209223506.GF9606@sandbox-ub \
--to=hvoigt@hvoigt.net \
--cc=charlie@charliedyson.net \
--cc=git@vger.kernel.org \
--cc=jens.lehmann@web.de \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).