serving git with both "git:" and "http:" and submodules

serving git with both "git:" and "http:" and submodules

[Boaz Harrosh]

I have a public tree that I maintain for users. The tree is consisted
of a main-tree and a submodule tree which is also served from the same
server.

The main tree:
git://my-domain.org/my-tree/.git
The sub-tree:
git://my-domain.org/my-tree/sub/.git

in my .gitmodule I have the usual
[submodule "sub"]
        url = git://my-domain.org/my-tree/sub/.git

So smart people using git will just do:
1. $ git clone git://my-domain.org/my-tree/.git
2. $ git submodule init
3. $ git submodule update

And all is well... But smart ass corporate people would not use "git:"
protocol because of fire-walls and for them I have a dumb "http:" export
as:
1. $ git clone http://my-domain.org/trees/my-tree/.git

With them, step 3 above will not work. My current instructions
for them is that after the step 2 "git submodule init" they should
manually edit my-tree/.git/config and change to:
[submodule "sub"]
-        url = git://my-domain.org/my-tree/sub/.git
+        url = http://my-domain.org/trees/my-tree/sub/.git

And then do step 3 to clone the sub-module.

So my question is: Can I automate this so people with "http:"
clones are not forced to manually edit their config files?
(Some users are just not up to it)

Thanks, (Sorry if that has been raised before. Couldn't find any.)
Boaz

Re: serving git with both "git:" and "http:" and submodules

[Jonathan Nieder]

Boaz Harrosh wrote:

> So smart people using git will just do:
> 1. $ git clone git://my-domain.org/my-tree/.git
> 2. $ git submodule init
> 3. $ git submodule update
> 
> And all is well... But smart ass corporate people would not use "git:"
> protocol because of fire-walls and for them I have a dumb "http:" export
> as:
> 1. $ git clone http://my-domain.org/trees/my-tree/.git
[...]
> So my question is: Can I automate this so people with "http:"
> clones are not forced to manually edit their config files?
> (Some users are just not up to it)

Sure.  For example, you can ship an update-submodules.sh script
to take care of checking “git config remote.origin.url” and
updating the ‘[submodule "sub"] url’ configuration to match.

Of course, even this would not make
'git clone --recursive http://my-domain.org/trees/my-tree/.git'
work.  If you can get git-http-backend working, I’d suggest using
that so you only have to deal with one url.

Hope that helps,
Jonathan

Re: serving git with both "git:" and "http:" and submodules

[Boaz Harrosh]

On 07/14/2010 06:39 PM, Jonathan Nieder wrote:
> Boaz Harrosh wrote:
> 
>> So smart people using git will just do:
>> 1. $ git clone git://my-domain.org/my-tree/.git
>> 2. $ git submodule init
>> 3. $ git submodule update
>>
>> And all is well... But smart ass corporate people would not use "git:"
>> protocol because of fire-walls and for them I have a dumb "http:" export
>> as:
>> 1. $ git clone http://my-domain.org/trees/my-tree/.git
> [...]
>> So my question is: Can I automate this so people with "http:"
>> clones are not forced to manually edit their config files?
>> (Some users are just not up to it)
> 
> Sure.  For example, you can ship an update-submodules.sh script
> to take care of checking “git config remote.origin.url” and
> updating the ‘[submodule "sub"] url’ configuration to match.
> 
> Of course, even this would not make
> 'git clone --recursive http://my-domain.org/trees/my-tree/.git'

Right

> work.  If you can get git-http-backend working, I’d suggest using
> that so you only have to deal with one url.
> 

Ok I'll dive into "git-http-backend" (any pointers). But I thought
this one will still serve me an "http:" url. Are you suggesting to
just drop the "git:" protocol? (Since "git-http-backend" is just as
good, through http?)

> Hope that helps,
> Jonathan

But a script for users might be a very good idea. I might even add
it to the main Makefile. And make it totally transparent.
$ git-clone; make;

Thanks that actually helped
Boaz

Re: serving git with both "git:" and "http:" and submodules

[Jonathan Nieder]

Boaz Harrosh wrote:

> Ok I'll dive into "git-http-backend" (any pointers).

The reference manual[1] is all I know of.  Googling reveals a
nice overview[2] by Scott Chacon.

>                                              Are you suggesting to
> just drop the "git:" protocol? (Since "git-http-backend" is just as
> good, through http?)

Exactly[3].

> Thanks that actually helped

Glad to be useful. :)

Good luck,
Jonathan

[1] http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
[2] http://progit.org/2010/03/04/smart-http.html
[3] Well, the protocol overhead is a little higher, but that is nothing
compared to the difference between git: and traditional static http:.

Re: serving git with both "git:" and "http:" and submodules

[Brad King]

On 07/14/2010 11:39 AM, Jonathan Nieder wrote:
> Boaz Harrosh wrote:
>> So my question is: Can I automate this so people with "http:"
>> clones are not forced to manually edit their config files?

Almost.

> Of course, even this would not make
> 'git clone --recursive http://my-domain.org/trees/my-tree/.git'
> work.

Firewall-ed users can just run

$ git config --global url.http://my-domain.org/.insteadOf git://my-domain.org/

*once* per user per machine, or even

$ git config --global url.http.insteadOf git

if they want to be really aggressive.  After that they can just
pretend to use the git protocol and all URLs will be mapped under
the hood:

  git clone --recursive git://my-domain.org/...

-Brad

Re: serving git with both "git:" and "http:" and submodules

[Peter Krefting]

Boaz Harrosh:

> [submodule "sub"]
>        url = git://my-domain.org/my-tree/sub/.git

> So my question is: Can I automate this so people with "http:" clones are 
> not forced to manually edit their config files?

You should be able to use a relative URL in .gitmodules, something like this 
should work:

[submodule "sub"]
        url = ../sub/.git

-- 
\\// Peter - http://www.softwolves.pp.se/

[PATCH] gitmodules.5: url can be a relative path

[Jonathan Nieder]

There is already excellent documentation for this facility in
git-submodule.1, but it is not so discoverable.

Relative paths in .gitmodules can be useful for serving the
same repository over multiple protocols, for example.
Thanks to Peter for pointing this out.

Cc: Peter Krefting <peter@softwolves.pp.se>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 Documentation/gitmodules.txt |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 5daf750..72a13d1 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -29,6 +29,9 @@ submodule.<name>.path::
 
 submodule.<name>.url::
 	Defines an url from where the submodule repository can be cloned.
+	This may be either an absolute URL ready to be passed to
+	linkgit:git-clone[1] or (if it begins with ./ or ../) a location
+	relative to the superproject's origin repository.
 
 submodule.<name>.update::
 	Defines what to do when the submodule is updated by the superproject.
-- 
1.7.2.rc2

[PATCH] Documentation: add submodule.* to the big configuration variable list

[Jonathan Nieder]

The url, path, and update items in [submodule "foo"] stanzas are
nicely explained in the .gitmodules and ‘git submodule’
documentation.  Point there from the config documentation.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
It’s late, so I don’t trust this to be coherent English necessarily.
Thoughts and improvements welcome.

 Documentation/config.txt |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1029bc4..f1fb5ac 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1685,6 +1685,15 @@ status.submodulesummary::
 	summary of commits for modified submodules will be shown (see
 	--summary-limit option of linkgit:git-submodule[1]).
 
+submodule.<name>.path::
+submodule.<name>.url::
+submodule.<name>.update::
+	The path within this project, URL, and updating strategy
+	for a submodule.  These variables are initially populated
+	by 'git submodule init'; edit them to override the
+	URL and other values found in the `.gitmodules` file.  See
+	linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.
+
 tar.umask::
 	This variable can be used to restrict the permission bits of
 	tar archive entries.  The default is 0002, which turns off the
-- 
1.7.2.rc2

Re: [PATCH] Documentation: add submodule.* to the big configuration variable list

[Johan Herland]

On Thursday 15 July 2010, Jonathan Nieder wrote:
> The url, path, and update items in [submodule "foo"] stanzas are
> nicely explained in the .gitmodules and ‘git submodule’
> documentation.  Point there from the config documentation.
> 
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

Acked-by: Johan Herland <johan@herland.net>

> ---
> It’s late, so I don’t trust this to be coherent English necessarily.
> Thoughts and improvements welcome.
> 
>  Documentation/config.txt |    9 +++++++++
>  1 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 1029bc4..f1fb5ac 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1685,6 +1685,15 @@ status.submodulesummary::
>  	summary of commits for modified submodules will be shown (see
>  	--summary-limit option of linkgit:git-submodule[1]).
> 
> +submodule.<name>.path::
> +submodule.<name>.url::
> +submodule.<name>.update::
> +	The path within this project, URL, and updating strategy

May be more legible with:

  The path within this project, the URL, and the updating strategy...


...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: [PATCH] Documentation: add submodule.* to the big configuration variable list

[Jonathan Nieder]

Johan Herland wrote:

> May be more legible with:
> 
>   The path within this project, the URL, and the updating strategy...

Thanks, Johan.  I’ve pushed both patches out to
  git://repo.or.cz/git/jrn.git submodule-doc
including that change.

Jonathan Nieder (2):
      gitmodules.5: url can be a relative path
      Documentation: add submodule.* to the big configuration variable list

 Documentation/config.txt     |    9 +++++++++
 Documentation/gitmodules.txt |    3 +++
 2 files changed, 12 insertions(+), 0 deletions(-)

Re: [PATCH] gitmodules.5: url can be a relative path

[Johan Herland]

On Thursday 15 July 2010, Jonathan Nieder wrote:
> There is already excellent documentation for this facility in
> git-submodule.1, but it is not so discoverable.
> 
> Relative paths in .gitmodules can be useful for serving the
> same repository over multiple protocols, for example.
> Thanks to Peter for pointing this out.
> 
> Cc: Peter Krefting <peter@softwolves.pp.se>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

Acked-by: Johan Herland <johan@herland.net>

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: [PATCH] gitmodules.5: url can be a relative path

[Boaz Harrosh]

On 07/15/2010 10:41 AM, Jonathan Nieder wrote:
> There is already excellent documentation for this facility in
> git-submodule.1, but it is not so discoverable.
> 
> Relative paths in .gitmodules can be useful for serving the
> same repository over multiple protocols, for example.
> Thanks to Peter for pointing this out.
> 

You guys rock. It's exactly what the doctor ordered

Thanks
Boaz