Re: Re: Relative submodule URLs

From: Robert Dailey <rcdailey.lists@gmail.com>
Date: Aug 25, 2014, 14:29 UTC
Message-ID: <CAHd499Bat5AFc1E4Sfezx9Qi8LPsxkyKKkBb2eg8JQb9kdPzgg@mail.gmail.com>
In-Reply-To: <20140824133428.GA2839@book.hvoigt.net>

On Sun, Aug 24, 2014 at 8:34 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:

Show 40 quoted lines

> 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
> Robert proposed here[2].
>
> For that we do not have to worry about how it can be stored,
> transported, defined per submodule or on a branch, since answers to this
> are given at the commandline (and current repository state).
>
> There are still open questions about this though:
>
>   * Should the name in the submodule be 'origin' even though you
>     specified --with-remote=somewhere? For me its always confusing to
>     have the same/similar remotes named differently in different
>     repositories. That why I try to keep the names the same in all my
>     clones of repositories (i.e. for my private, github, upstream
>     remotes).
>
>   * When you do a 'git submodule sync --with-remote=somewhere' should
>     the remote be added or replaced.
>
> My opinion on these are:
>
> The remote should be named as in the superproject so
> --with-remote=somewhere adds/replaces the remote 'somewhere' in the
> submodules named on the commandline (or all in case no submodule is
> specified). In case of a fresh clone of the submodule, there would be no
> origin but only a remote under the new name.
>
> Would the --with-remote feature I describe be a feasible start for you
> Robert? What do others think? Is the naming of the parameter
> '--with-remote' alright?
>
> Cheers Heiko
>
> [1] http://article.gmane.org/gmane.comp.version-control.git/255512
> [2] http://article.gmane.org/gmane.comp.version-control.git/255512
> [3] https://github.com/jlehmann/git-submod-enhancements/wiki#special-ref-overriding-gitmodules-values

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 you first. At this point my only intention was to start discussion on a possible short-term solution. I realize the Git developers are working hard on improving submodule workflow for the long term. In addition I do not have the domain expertise to properly make suggestions in regards to longer-term solutions, so I leave that to you :-)

The --with-remote feature would allow me to begin using relative submodules because:

On a per-submodule basis, I can specify the remote it will use. When I fork a submodule and need to start tracking it, I can run `git submodule sync --with-remote fork`, which will take my super repo's 'fork' remote, REPLACE 'origin' in the submodule with that URL, and also redo the relative URL calculation. This is ideal since I use HTTP at home (so I can use my proxy server to access git behind firewall at work) and at work physically I use SSH for performance (to avoid HTTP protocol). I also like the idea of "never" having to update my submodule URLs again if the git server moves, domain name changes, or whatever else.

Here is what I think would make the feature most usable. I think you went over some of these ideas but I just want to clarify, to make sure we're on the same page. Please correct me as needed.

1. Running `git submodule update --with-remote <name>` shall fail the
command unconditionally.
2. Using the `--with-remote` option on submodule `update` or `sync`
will fail if it detects absolute submodule URLs in .gitmodule
3. Running `git submodule update --init --with-remote <name>` shall
fail the command ONLY if a submodule is being processed that is NOT
also being initialized.
4. The behavior of git submodule's `update` or `sync` commands
combined with `--with-remote` will REPLACE or CREATE the 'origin'
remote in each submodule it is run in. We will not allow the user to
configure what the submodule remote name will end up being (I think
this is current behavior and forces good practice; I consider `origin`
an adopted standard for git, and actually wish it was more enforced
for super projects as well!)

Let me know if I've missed anything. Once we clarify requirements I'll attempt to start work on this during my free time. I'll start by testing this through msysgit, since I do not have linux installed, but I have Linux Mint running in a Virtual Machine so I can test on both platforms as needed (I don't have a lot of experience on Linux though).

I hope you won't mind me reaching out for questions as needed, however I will attempt to be as resourceful as possible since I know you're all busy. Thanks.