git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heiko Voigt <hvoigt@hvoigt.net>
To: Robert Dailey <rcdailey.lists@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Jonathan Nieder <jrnieder@gmail.com>, Git <git@vger.kernel.org>,
	Jens Lehmann <Jens.Lehmann@web.de>
Subject: Re: Re: Relative submodule URLs
Date: Tue, 19 Aug 2014 21:30:10 +0200	[thread overview]
Message-ID: <20140819193010.GA64203@book.hvoigt.net> (raw)
In-Reply-To: <CAHd499B9Wa=Y6P+OD8Ea-6dA4yZSkGZZSR9CwZAM45evDL_Qiw@mail.gmail.com>

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 to. 'origin' points to the place you push your
> changes for pull requests (the fork).
> 
> Basically the workflow I use is:
> 
> - Use 'upstream' to PULL changes (latest code is obtained from the
> authoritative repository)
> - Use 'origin' to push your branches. Since I never modify the
> branches that exist in 'upstream' on my 'origin' (I do everything
> through separate personal branches).
> 
> That means if I have a branch off of 'master' named 'topic', I will
> track 'upstream/master' and get latest with 'git pull'. When I'm ready
> for a pull request, I do 'git push origin' (I use push.default =
> simple).
> 
> According to my understanding, relative submodules work here. But not
> everyone on my team uses this workflow. Sometimes they track
> "origin/topic" (if we use my example again). Won't the submodule try
> to find itself on the fork now?

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 submodule like in a normal git repository that
you have freshly cloned. Which remote is used for cloning depends on the
configured remote for the current branch or 'origin'.

When you do a fetch or push with --recurse-submodules it only executes a
'git fetch' or 'git push' without any specific remote. For fetch the
same commandline options (but only the options) are passed on.

Here it might make sense to guess the remote in the submodule somehow
and not do what fetch without remotes would do.

For the triangular workflow not much work has been done in regards to
submodule support.

But since a submodule behaves like a normal git repository maybe there
is not much work needed and we can just point to the workflow without
submodules most times. We still have to figure that out properly.

Cheers Heiko

  parent reply	other threads:[~2014-08-19 19:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-18 18:22 Relative submodule URLs Robert Dailey
2014-08-18 20:55 ` Jonathan Nieder
2014-08-19 10:24   ` Heiko Voigt
2014-08-19 16:15     ` Robert Dailey
2014-08-19 16:39       ` Junio C Hamano
2014-08-19 16:50         ` Robert Dailey
2014-08-19 19:19           ` Junio C Hamano
2014-08-19 20:18             ` Robert Dailey
2014-08-19 19:30           ` Heiko Voigt [this message]
2014-08-19 20:23             ` Robert Dailey
2014-08-19 20:57               ` Heiko Voigt
2014-08-20 13:18                 ` Robert Dailey
2014-08-21 12:37                   ` Heiko Voigt
2014-08-19 16:07   ` Robert Dailey
2014-08-22 16:00     ` Marc Branchaud
2014-08-24 13:34       ` Heiko Voigt
2014-08-25 14:29         ` Robert Dailey
2014-08-25 14:32           ` Robert Dailey
2014-08-26  6:28           ` Heiko Voigt
2014-08-26 15:18             ` Robert Dailey
2014-08-26 20:34               ` Heiko Voigt
2014-08-25 13:48       ` Robert Dailey
2014-08-28 17:44       ` Marc Branchaud
2014-08-28 19:35         ` Heiko Voigt
2014-08-29 15:09           ` Marc Branchaud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140819193010.GA64203@book.hvoigt.net \
    --to=hvoigt@hvoigt.net \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=rcdailey.lists@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).