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 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 Fri, Aug 22, 2014 at 11:00 AM, Marc Branchaud marcn...@xiplink.com 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
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 14-08-19 12:07 PM, Robert Dailey wrote:
On Mon, Aug 18, 2014 at 3:55 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Thanks for reporting. The remote used is the default remote that git
fetch without further arguments would use:
get_default_remote () {
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 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 a
On Mon, Aug 18, 2014 at 3:55 PM, Jonathan Nieder jrnie...@gmail.com 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 symbolic-ref -q HEAD)
On Tue, Aug 19, 2014 at 5:24 AM, Heiko Voigt hvo...@hvoigt.net 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?
Robert Dailey rcdailey.li...@gmail.com 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'
On Tue, Aug 19, 2014 at 11:39 AM, Junio C Hamano gits...@pobox.com wrote:
Robert Dailey rcdailey.li...@gmail.com 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
Robert Dailey rcdailey.li...@gmail.com 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'
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:19 PM, Junio C Hamano gits...@pobox.com 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
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
Hi,
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 a
general terminology).
Thanks for reporting. The remote used is the
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.
$
Thanks for taking time to understand, let me make it more clear
Le 12 juin 2014 à 17:25, Fredrik Gustafsson iv...@iveqy.com 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
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
26 matches
Mail list logo
