On Thu, Aug 28, 2014 at 01:44:18PM -0400, Marc Branchaud wrote:
Heiko also said this:
On Fri, Aug 22, 2014 at 12:00:07PM -0400, Marc Branchaud wrote:
With relative-path submodules, the push's target repo *must* also have the
submodules in their proper places, so that they can get updated.
On Mon, Aug 25, 2014 at 09:29:07AM -0500, Robert Dailey wrote:
On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt hvo...@hvoigt.net wrote:
New --with--remote parameter for 'git submodule'
While having said all that about submodule settings I
On Tue, Aug 26, 2014 at 1:28 AM, Heiko Voigt hvo...@hvoigt.net wrote:
Hi Heiko,
My last email response was in violation of your request to keep the
two topics separate, sorry about that. I started typing it this
weekend and completed the draft this morning, without having read this
response
On Tue, Aug 26, 2014 at 10:18:48AM -0500, Robert Dailey wrote:
On Tue, Aug 26, 2014 at 1:28 AM, Heiko Voigt hvo...@hvoigt.net wrote:
My last email response was in violation of your request to keep the
two topics separate, sorry about that. I started typing it this
weekend and completed the
On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt hvo...@hvoigt.net wrote:
New --with--remote parameter for 'git submodule'
While having said all that about submodule settings I think a much
much simpler start is to go ahead with a commandline
On Mon, Aug 25, 2014 at 9:29 AM, Robert Dailey rcdailey.li...@gmail.com wrote:
On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt hvo...@hvoigt.net wrote:
New --with--remote parameter for 'git submodule'
While having said all that about submodule
Hi,
since the mail got quite long. To avoid 'tl;dr', I talk about two topics
in this mail:
* Submodule settings for default remote (complex, future)
* New --with--remote parameter for 'git submodule' (simple, now)
Depending on your interest you might want to skip the first part of the
On Wed, Aug 20, 2014 at 08:18:12AM -0500, Robert Dailey wrote:
On Tue, Aug 19, 2014 at 3:57 PM, Heiko Voigt hvo...@hvoigt.net wrote:
I would actually error out when specified in already cloned state.
Because otherwise the user might expect the remote to be updated.
Since we are currently
On Tue, Aug 19, 2014 at 3:57 PM, Heiko Voigt hvo...@hvoigt.net wrote:
I would actually error out when specified in already cloned state.
Because otherwise the user might expect the remote to be updated.
Since we are currently busy implementing recursive fetch and checkout I have
added that to
On Tue, Aug 19, 2014 at 11:50:08AM -0500, Robert Dailey wrote:
Maybe I'm misunderstanding something here and you can help me out.
All the reading I've done (mostly github) says that 'upstream' points
to the authoritative repository that you forked from but do not have
permissions to write
On Tue, Aug 19, 2014 at 2:30 PM, Heiko Voigt hvo...@hvoigt.net wrote:
Well the remote for the submodule is currently only calculated once,
when you do the initial
git submodule update --init
that clones the submodule. Afterwards the fixed url is configured under
the name 'origin' in
On Tue, Aug 19, 2014 at 03:23:36PM -0500, Robert Dailey wrote:
On Tue, Aug 19, 2014 at 2:30 PM, Heiko Voigt hvo...@hvoigt.net wrote:
Well the remote for the submodule is currently only calculated once,
when you do the initial
git submodule update --init
that clones the
12 matches
Mail list logo