On Tue, Oct 23, 2012 at 03:44:36PM -0400, W. Trevor King wrote: > On Tue, Oct 23, 2012 at 12:16:22PM -0700, Nahor wrote: > > On 2012-10-22 09:34, W. Trevor King wrote: > > For instance, the module may later be updated to a commit in branch B > > instead of branch A. Unless you remember to also update .gitmodule, you > > have then inconsistent information. > > But you're explicitly *using* the configured setting in > > git config --file $toplevel/.gitmodules submodule.$name.branch > > That should be a reminder that the configuration is important, and > you'll remember to change it.
To make my case more cleanly, people already handle all the troublesome cases for branch.$name.remote, so handling similar upstream volatility for submodule.$name.branch should not be too difficult or surprising. On Tue, Oct 23, 2012 at 03:58:48PM -0400, Phil Hord wrote: > On Mon, Oct 22, 2012 at 6:55 PM, W. Trevor King <wk...@tremily.us> wrote: > > How about -r/--record, with the recorded name being optional? > > > > --record-branch[=<recorded_name>] > > I like that just fine. > > > This would satisfy Gerrit users that wanted to use '.', but also > > satisfy me with: > > > > git submodule add -rb=master foo bar > > > > However, there is a change that people would see that, and then use > > > > git submodule add -r -b=master foo bar > > > > which would checkout the HEAD from foo and store `-b=master` in > > submodule.$name.branch. > > I don't think it would. Ah, right, forcing the =<name> attached case would mean they'd have to use git submodule add -r=-b=master which doesn't sound like the sort of thing you'd do accidentally. > Though I see in rev-parse--parseopts that the use of > optional-argument options "is discouraged". I'll work up a v2 patch and we'll see if anyone complains ;). -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Description: OpenPGP digital signature