Re: [PATCH] Make 'submodule update' honor the 'update' setting in .gitmodules.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mikhail Glushenkov <foldr@xxxxxxxxxxxxx> 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?

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]