Re: [PATCH] git-submodule add: Record branch name in .gitmodules

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:

quoted

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 [off-list ref] wrote:

quoted

How about -r/--record, with the recorded name being optional?

  --record-branch[=<recorded_name>]

I like that just fine.

quoted

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