# Re: [RFC v2] submodule: Respect requested branch on all clones

2 messages from 2014-01-07 to 2014-01-07. Participants: W. Trevor King, Francesco Pretto.
Thread: https://gitlist.dev/t/35624

## W. Trevor King, 2014-01-07 21:37

Subject: Re: [RFC v2] submodule: Respect requested branch on all clones
Message-ID: <20140107213739.GA29954@odin.tremily.us>
URL: https://gitlist.dev/e/20140107213739.GA29954%40odin.tremily.us
In-Reply-To: <CALas-iizoBjTu2KSXsZExNeLz5hxbzoNNGgYLMP9SmDH+kt9Vw@mail.gmail.com>

```
On Tue, Jan 07, 2014 at 09:09:19PM +0100, Francesco Pretto wrote:
> 2014/1/7 W. Trevor King <wking@tremily.us>:
> >> Trevor, maybe it was not clear. But I wanted to say:
> >>
> >> " I fully support *Trevor's* patch..." :)
> >
> > Which I appreciate ;).  I still though I should point out that my
> > patch *confuses* the role of submodule.<name>.branch :p.
> 
> You are welcome. Also, at your wish, can you please reply also in
> public?

Here you go.

I'd be happy to hear ideas about superproject-branch-specific local
overrides to a hypothetical submodule.<name>.local-branch, in the
event that a developer doesn't like a default set in .gitmodules.  If
I could think of a way to do that, we could avoid this heuristic
approach, and make the local submodule.<name>.local-branch
vs. remote-tracking submodule.<name>.branch distinction more obvious.

It would also be nice if submodule.<name>.branch was just an initial
setup-time and detached-HEAD default.  If the submodule is on a branch
it would make more sense to use the checked-out branch's @{upstream}.

Cheers,
Trevor

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

```

## Francesco Pretto, 2014-01-07 21:51

Subject: Re: [RFC v2] submodule: Respect requested branch on all clones
Message-ID: <CALas-iiH0GCwy9WMWxBSGbUykwAKikaLUhfdDUbETv91QuM-7g@mail.gmail.com>
URL: https://gitlist.dev/e/CALas-iiH0GCwy9WMWxBSGbUykwAKikaLUhfdDUbETv91QuM-7g%40mail.gmail.com
In-Reply-To: <20140107213739.GA29954@odin.tremily.us>

```
2014/1/7 W. Trevor King <wking@tremily.us>:
>
> I'd be happy to hear ideas about superproject-branch-specific local
> overrides to a hypothetical submodule.<name>.local-branch, in the
> event that a developer doesn't like a default set in .gitmodules.  If
> I could think of a way to do that, we could avoid this heuristic
> approach, and make the local submodule.<name>.local-branch
> vs. remote-tracking submodule.<name>.branch distinction more obvious.
>

Uh, I think you got it wrong in the other thread: I didn't proposed
such feature. I just wanted the attached submodule use case to be
supported and of course "--branch means attached" is even easier to
get this.

```