On 14-08-28 03:35 PM, Heiko Voigt wrote:
> 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
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 up
Sorry for dropping out of the conversation; the last few days were a bit hectic.
Regarding recursive branching, I agree that a super-repo's branch names are
not necessarily appropriate for its submodules, and that Heiko's "simple
workflow" is a workable base to build upon. More thought is needed
On Tue, Aug 26, 2014 at 10:18:48AM -0500, Robert Dailey wrote:
> On Tue, Aug 26, 2014 at 1:28 AM, Heiko Voigt 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 draft th
On Tue, Aug 26, 2014 at 1:28 AM, Heiko Voigt 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 from y
On Mon, Aug 25, 2014 at 09:29:07AM -0500, Robert Dailey wrote:
> On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt wrote:
> > New --with--remote parameter for 'git submodule'
> >
> >
> > While having said all that about submodule settings I think a much
On Mon, Aug 25, 2014 at 9:29 AM, Robert Dailey wrote:
> On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt wrote:
>> New --with--remote parameter for 'git submodule'
>>
>>
>> While having said all that about submodule settings I think a much
>> much simp
On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt 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 setting, like
> Ro
On Fri, Aug 22, 2014 at 11:00 AM, Marc Branchaud wrote:
> A couple of years ago I started to work on such a thing ([1] [2] [3]), mainly
> because when we tried to change to relative submodules we got bitten when
> someone used clone's -o option so that his super-repo had no "origin" remote
> *and*
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
email.
On 14-08-19 12:07 PM, Robert Dailey wrote:
> On Mon, Aug 18, 2014 at 3:55 PM, Jonathan Nieder wrote:
>> Thanks for reporting. The remote used is the default remote that "git
>> fetch" without further arguments would use:
>>
>> get_default_remote () {
>> curr_branch=$(git s
On Wed, Aug 20, 2014 at 08:18:12AM -0500, Robert Dailey wrote:
> On Tue, Aug 19, 2014 at 3:57 PM, Heiko Voigt 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 impl
On Tue, Aug 19, 2014 at 3:57 PM, Heiko Voigt 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 our ideas li
On Tue, Aug 19, 2014 at 03:23:36PM -0500, Robert Dailey wrote:
> On Tue, Aug 19, 2014 at 2:30 PM, Heiko Voigt 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. A
On Tue, Aug 19, 2014 at 2:30 PM, Heiko Voigt 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 the submod
On Tue, Aug 19, 2014 at 2:19 PM, Junio C Hamano wrote:
>
> I do not know if that is how GitHub teaches people, but I would have
> to say that these are strange phrasing. I suspect that part of
> their documentation was written long time ago, back when nobody on
> the GitHub side were involved in
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 writ
Robert Dailey writes:
> 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 to. 'origin' points to the place you p
On Tue, Aug 19, 2014 at 11:39 AM, Junio C Hamano wrote:
> Robert Dailey writes:
>
>> The way I set up my remote tracking branch will be different for each
>> of these commands:
>>
>> - git pull :: If I want convenient pulls (with rebase), I will track
>> my upstream branch. My pushes have to be m
Robert Dailey writes:
> The way I set up my remote tracking branch will be different for each
> of these commands:
>
> - git pull :: If I want convenient pulls (with rebase), I will track
> my upstream branch. My pushes have to be more explicit as a tradeoff.
Keeping 'origin' pointing at the rep
On Tue, Aug 19, 2014 at 5:24 AM, Heiko Voigt wrote:
> I think the OP problem stems from him having a branch that does not have a
> remote configured. Since they do not have 'origin' as a remote and
>
> git submodule update --init --recursive path/to/submodule
>
> fails. Right?
Not exactly
rio:
[branch.myfoo]
remote = origin
submoduleRemote = upstream
I can track an origin branch, but the submodule will refer to 'upstream'.
I can optionally set `submodule.remote` in my global config so I don't
need to set the submodule remote on each branch. This is useful
On Mon, Aug 18, 2014 at 01:55:05PM -0700, Jonathan Nieder wrote:
> Robert Dailey wrote:
>
> > The documentation wasn't 100% clear on this, but I'm assuming by
> > "remote origin", it says that the relative URL is relative to the
> > actual remote *named* origin (and it is not using origin as just
ault = whereishouldpush
and then 'git fetch' and 'git fetch --recurse-submodules' will fetch
from "origin" and 'git push' will push to the whereishouldpush remote.
It might make sense to introduce a new
[remote]
default = whereis
The documentation wasn't 100% clear on this, but I'm assuming by
"remote origin", it says that the relative URL is relative to the
actual remote *named* origin (and it is not using origin as just a
general terminology).
Is there a way to specify (on a per-clone basis) which named remote
will be us
On Thu, Jun 12, 2014 at 06:05:10PM +0200, Charles Brossollet wrote:
> The two problems I'm pointing are:
>
> 1. After checkout of a branch that tracks /user/main repo, call git
>init submodule motors. Git registers it in .git/config with URL
>/user/sub, while it should be /central/sub acco
Thanks for taking time to understand, let me make it more clear
Le 12 juin 2014 à 17:25, Fredrik Gustafsson a écrit :
> So let me see if I understand you correctly.
>
>
> On Wed, Jun 11, 2014 at 12:15:39PM +0200, Charles Brossollet wrote:
>> Hi,
>>
>> I'm banging my head on this problem: I ha
So let me see if I understand you correctly.
On Wed, Jun 11, 2014 at 12:15:39PM +0200, Charles Brossollet wrote:
> Hi,
>
> I'm banging my head on this problem: I have a central repo cloned by SSH, and
> a fork on the same server. The central remote is origin, and the fork is
> chbrosso-wip.
>
Hi,
I'm banging my head on this problem: I have a central repo cloned by SSH, and a
fork on the same server. The central remote is origin, and the fork is
chbrosso-wip.
$ git remote -v | grep origin
origin chbrosso@lltech:/git/lightct.git (fetch)
origin chbrosso@lltech:/git/lightct.git (push)
29 matches
Mail list logo
