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

From: W. Trevor King <wking@tremily.us>
Date: Oct 23, 2012, 20:44 UTC
Message-ID: <20121023204437.GE28592@odin.tremily.us>
In-Reply-To: <CABURp0q7TJM_0E7g8EAB9jQ2q6rNcvncOqYnk4byehQxbZfo1w@mail.gmail.com>

On Tue, Oct 23, 2012 at 03:44:36PM -0400, W. Trevor King wrote:

Show 12 quoted lines

> 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:

Show 20 quoted lines

> On Mon, Oct 22, 2012 at 6:55 PM, W. Trevor King <wking@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