On Mon, Oct 29, 2012 at 06:21:08PM -0400, Phil Hord wrote:
> > Maybe instead of blindly converting config into the environment, it
> > should forward or clear specific known-meaning config.
>
> Well, that's where we started. I was aiming for the more generic
> "never needs updating" direction.
On Mon, Oct 29, 2012 at 5:36 PM, Jeff King wrote:
> On Mon, Oct 29, 2012 at 01:38:28PM -0400, Phil Hord wrote:
>
>> > I am not sure it is sufficient as-is, though. It does not seem to ever
>> > clear variables, only set them, which means that values could leak
>> > across iterations of the loop,
On Mon, Oct 29, 2012 at 01:38:28PM -0400, Phil Hord wrote:
> > I am not sure it is sufficient as-is, though. It does not seem to ever
> > clear variables, only set them, which means that values could leak
> > across iterations of the loop, [...] E.g., when
> > the first submodule has submodule.*.
On Mon, Oct 29, 2012 at 7:43 AM, Jeff King wrote:
> On Mon, Oct 29, 2012 at 07:29:45AM -0400, W. Trevor King wrote:
>
>> On Mon, Oct 29, 2012 at 06:58:55AM -0400, Jeff King wrote:
>> > Can you send an updated version of the patch that summarizes the
>> > situation in the commit message?
>>
>> Sure
On Mon, Oct 29, 2012 at 07:29:45AM -0400, W. Trevor King wrote:
> On Mon, Oct 29, 2012 at 06:58:55AM -0400, Jeff King wrote:
> > Can you send an updated version of the patch that summarizes the
> > situation in the commit message?
>
> Sure. Should I include Phil's $submodule_ export, or would
>
On Mon, Oct 29, 2012 at 06:58:55AM -0400, Jeff King wrote:
> Can you send an updated version of the patch that summarizes the
> situation in the commit message?
Sure. Should I include Phil's $submodule_ export, or would
you rather have that be a separate series?
Phil, were you planning on rollin
On Mon, Oct 29, 2012 at 06:45:44AM -0400, W. Trevor King wrote:
> > > Ah, good, then we *are* all using the option for the same thing.
> >
> > That makes me more comfortable. Your patch adds support for setting the
> > variable initially. Does it need any special magic for maintenance, or
> > is
On Mon, Oct 29, 2012 at 01:34:01AM -0400, Jeff King wrote:
> On Sun, Oct 28, 2012 at 06:34:31PM -0400, W. Trevor King wrote:
>
> > On Sun, Oct 28, 2012 at 02:59:33PM -0700, Shawn Pearce wrote:
> > > Looks like the Gerrit meaning is basically the same as Ævar's. Gerrit
> > > updates the parent proj
On Sun, Oct 28, 2012 at 06:34:31PM -0400, W. Trevor King wrote:
> On Sun, Oct 28, 2012 at 02:59:33PM -0700, Shawn Pearce wrote:
> > Looks like the Gerrit meaning is basically the same as Ævar's. Gerrit
> > updates the parent project as if you had done:
> >
> > $ git submodule foreach 'git check
On Sun, Oct 28, 2012 at 02:59:33PM -0700, Shawn Pearce wrote:
> Looks like the Gerrit meaning is basically the same as Ævar's. Gerrit
> updates the parent project as if you had done:
>
> $ git submodule foreach 'git checkout $(git config --file
> $toplevel/.gitmodules submodule.$name.branch) &&
On Sun, Oct 28, 2012 at 1:48 PM, Jens Lehmann wrote:
> Am 23.10.2012 22:55, schrieb W. Trevor King:
>> As Phil pointed out, doing anything with this variable is ambiguous:
>>
>> On Mon, Oct 22, 2012 at 06:03:53PM -0400, Phil Hord wrote:
>>> Some projects now use the 'branch' config value to record
On Sun, Oct 28, 2012 at 09:48:18PM +0100, Jens Lehmann wrote:
> Am 25.10.2012 02:53, schrieb W. Trevor King:
> > On Wed, Oct 24, 2012 at 09:15:32PM +0200, Jens Lehmann wrote:
> >> I still fail to see what adding that functionality to the submodule
> >> command buys us (unless we also add code which
Am 25.10.2012 02:53, schrieb W. Trevor King:
> On Wed, Oct 24, 2012 at 09:15:32PM +0200, Jens Lehmann wrote:
>> I still fail to see what adding that functionality to the submodule
>> command buys us (unless we also add code which really uses the branch
>> setting). What's wrong with doing a simple:
On Thu, Oct 25, 2012 at 06:14:31PM -0400, W. Trevor King wrote:
> Should I rebase this so it lands cleanly atop 38ae92e4 in next?
>
> commit 38ae92e4d027063b9b87e51a9bf12809d10066f6
> Author: W. Trevor King
> Date: Tue Oct 23 17:00:21 2012 -0400
>
> git-submodule: wrap branch option
Should I rebase this so it lands cleanly atop 38ae92e4 in next?
commit 38ae92e4d027063b9b87e51a9bf12809d10066f6
Author: W. Trevor King
Date: Tue Oct 23 17:00:21 2012 -0400
git-submodule: wrap branch option with "<>" in usage strings.
--
This email may be signed or encrypted with Gn
On Wed, Oct 24, 2012 at 09:15:32PM +0200, Jens Lehmann wrote:
> I still fail to see what adding that functionality to the submodule
> command buys us (unless we also add code which really uses the branch
> setting). What's wrong with doing a simple:
>
>git config -f .gitmodules submodule..bran
I still fail to see what adding that functionality to the submodule
command buys us (unless we also add code which really uses the branch
setting). What's wrong with doing a simple:
git config -f .gitmodules submodule..branch
on the command line when you want to use the branch setting for you
From: "W. Trevor King"
This option allows you to record a submodule..branch option in
.gitmodules. Git does not currently use this configuration option for
anything, but users have used it for several things, so it makes sense
to add some syntactic sugar for initializing the value.
Current cons
18 matches
Mail list logo
