Re: [PATCH] Make 'submodule update' honor the 'update' setting in .gitmodules.
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 7, 2009, 21:54 UTC
- Message-ID
- <7veirns30y.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <1249530977-17501-1-git-send-email-foldr@codedgers.com>
Mikhail Glushenkov <foldr@codedgers.com> writes:
> Make the 'submodule update' command honor the 'submodule.$path.update' setting > in .gitmodules unless this setting is overridden in '.git/config' or with > --rebase/--merge options.
I haven't been involved in recent updates to "git submodule", but the change in this patch feels somewhat wrong.
The contents of in-tree .gitmodules are meant to be consulted to only prime the settings in .git/config, and after that they are never used without user's explicit concent (e.g. "sync"). At least that is the way I understand how the current "git submodule" command is designed.
This change actively breaks the pattern. It makes sense to set up values for "submodule.*.update" when the defaults suggested by the project are copied out of .gitmodules to prime .git/config upon "submodule init", but not at runtime in "update" command like this.
I am puzzled. What problem are you trying to solve?
"submodule init" seems to already copy "update" setting from .gitmodules to .git/config. At least, it seems to have a code to try to do so.
Perhaps you would want to (1) add the "submodule.*.update" to the set of configurations to be copied upon "sync", not just URL? and (2) add a way to allow users to inspect how values in .git/config and .gitmodules are different, and update .git/config with selected values, possibly in an interactive manner?