[PATCH 0/3] [RFC] Support for publishing projects at central site

[PATCH 0/3] [RFC] Support for publishing projects at central site

[pasky]

This series implements a special variant of the 'add remote' dialog
designed for publishing new projects at a central site - it fixes
certain parameters and launches web browser during the push for
project registration in a repo.or.cz-like fashion. The feature is
aimed especially at corporate Git deployment.

This is not really meant for as-is application, of course, but more
to see if people think it is good idea to have this kind of functionality
in git-gui at all and how generic it should be. This mini-series depends
on pretty much all the other patches I have submitted tonight.

[PATCH 1/3] git web--browse: Add --stdin option support

[pasky]

[-- Attachment #1: t/web--browse/stdin.diff --]
[-- Type: text/plain, Size: 1868 bytes --]

This ugly hack seems to be necessary to safely pass URLs containing
query string even in the MinGW environment from TCL (git-gui). I admit
that it is not nice, but I at least did not manage to find any other
way to achieve that even after spending very long time debugging this
mysterious problem.

This patch has been sponsored by Novartis.

Signed-off-by: Petr Baudis <pasky@suse.cz>

---
 Documentation/git-web--browse.txt |    5 ++++-
 git-web--browse.sh                |    6 +++++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-web--browse.txt b/Documentation/git-web--browse.txt
index 7f7a45b..15d2c25 100644
--- a/Documentation/git-web--browse.txt
+++ b/Documentation/git-web--browse.txt
@@ -7,7 +7,7 @@ git-web--browse - git helper script to launch a web browser
 
 SYNOPSIS
 --------
-'git web--browse' [OPTIONS] URL/FILE ...
+'git web--browse' [OPTIONS] {--stdin,URL/FILE...}
 
 DESCRIPTION
 -----------
@@ -45,6 +45,9 @@ OPTIONS
 	CONF.VAR is looked up in the git config files. If it's set,
 	then its value specify the browser that should be used.
 
+--stdin::
+	Read the location to open from stdin.
+
 CONFIGURATION VARIABLES
 -----------------------
 
diff --git a/git-web--browse.sh b/git-web--browse.sh
index 384148a..68234fa 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -16,7 +16,7 @@
 # git maintainer.
 #
 
-USAGE='[--browser=browser|--tool=browser] [--config=conf.var] url/file ...'
+USAGE='[--browser=browser|--tool=browser] [--config=conf.var] {--stdin,url/file...}'
 
 # This must be capable of running outside of git directory, so
 # the vanilla git-sh-setup should not be used.
@@ -71,6 +71,10 @@ do
 		    shift ;;
 	    esac
 	    ;;
+	--stdin*)
+	    shift
+	    set "$(cat)"
+	    break ;;
 	--)
 	    break
 	    ;;
-- 
tg: (c427559..) t/web--browse/stdin (depends on: vanilla/master)

[PATCH 2/3] git-gui: Use git web--browse --stdin for safe URL passing

[pasky]

[-- Attachment #1: t/git-gui/web-browse-stdin.diff --]
[-- Type: text/plain, Size: 972 bytes --]

The current code does not actually require this since the documentation
URL should always pass through unmangled, but future users of
start_browser() (as in the patch to follow) might require this.

This patch has been sponsored by Novartis.

Signed-off-by: Petr Baudis <pasky@suse.cz>

---
 git-gui/git-gui.sh |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index fc67eb8..4d2d600 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -2360,7 +2360,11 @@ if {[file isfile $doc_path]} {
 }
 
 proc start_browser {url} {
-	git "web--browse" $url
+	# We use --stdin here since passing URLs (especially with query
+	# strings) does insane things in MSysGit.
+	set fd [git_write "web--browse" "--stdin"]
+	puts $fd $url
+	close $fd
 }
 
 .mbar.help add command -label [mc "Online Documentation"] \
-- 
tg: (6e32399..) t/git-gui/web-browse-stdin (depends on: t/git-gui/web-browse t/web--browse/stdin)

[PATCH 3/3] [FYI]git-gui: repo.or.cz-ish fork integration

[pasky]

[-- Attachment #1: t/git-gui/remote-publish.diff --]
[-- Type: text/plain, Size: 5507 bytes --]

During my internship at Novartis, I have deployed a local instance of the
repo.or.cz software and for our Git deployment, some kind of integration with
git-gui was very desirable - if someone makes local changes in his repository,
he can easily publish them on the local repo.or.cz instance as a fork of the
original project. They can use the extra 'Register on repo.or.cz' item in the
'Remote' menu, which will enforce the default locator and aside of initializing
the remote repository and pushing will also open the web browser with the
project registration form of repo.or.cz.

I'm not sure if something like this would be desirable for upstream, even as an
optional feature, and to what degree should it be configurable - but I imagine
that something like this could be very useful for corporate Git deployments
especially among less technical users and in scenarios using some kind of
central place to store all the repositories. Perhaps people deploying Git
in these cases will find the patch useful to apply locally even if it won't
end up merged.

This patch has been sponsored by Novartis.

Signed-off-by: Petr Baudis <pasky@suse.cz>

---
 git-gui/git-gui.sh         |    4 ++++
 git-gui/lib/remote_add.tcl |   42 +++++++++++++++++++++++++++++++++++++-----
 git-gui/lib/transport.tcl  |    7 +++++++
 3 files changed, 48 insertions(+), 5 deletions(-)

diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index aef9d66..a79d734 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -2305,6 +2305,10 @@ if {[is_enabled transport]} {
 	menu .mbar.remote
 
 	.mbar.remote add command \
+		-label [mc "Register on repo.or.cz"] \
+		-command remote_add::dialog_reg \
+		-accelerator $M1T-L
+	.mbar.remote add command \
 		-label [mc "Add..."] \
 		-command remote_add::dialog \
 		-accelerator $M1T-A
diff --git a/git-gui/lib/remote_add.tcl b/git-gui/lib/remote_add.tcl
index 94662fb..fb43abd 100644
--- a/git-gui/lib/remote_add.tcl
+++ b/git-gui/lib/remote_add.tcl
@@ -6,22 +6,36 @@ class remote_add {
 field w              ; # widget path
 field w_name         ; # new remote name widget
 field w_loc          ; # new remote location widget
+field is_reg        0; # are we the REGistering dialog, or normal add remote?
+field base_name      ; # name of base project if is_reg
 
 field name         {}; # name of the remote the user has chosen
 field location     {}; # location of the remote the user has chosen
 
-field opt_action fetch; # action to do after registering the remote locally
+field opt_action   {}; # action to do after registering the remote locally
 
-constructor dialog {} {
+proc dialog {} {
+	dialog_create "" 0 "fetch" "Add New Remote"
+}
+
+proc dialog_reg {} {
+	dialog_create "public" 1 "push" "Register On repo.or.cz"
+}
+
+constructor dialog_create {name_ is_reg_ opt_action_ title} {
 	global repo_config
 
+	set name $name_
+	set is_reg $is_reg_
+	set opt_action $opt_action_
+
 	make_toplevel top w
-	wm title $top [append "[appname] ([reponame]): " [mc "Add Remote"]]
+	wm title $top [append "[appname] ([reponame]): " [mc $title]]
 	if {$top ne {.}} {
 		wm geometry $top "+[winfo rootx .]+[winfo rooty .]"
 	}
 
-	label $w.header -text [mc "Add New Remote"] -font font_uibold
+	label $w.header -text [mc $title] -font font_uibold
 	pack $w.header -side top -fill x
 
 	frame $w.buttons
@@ -49,7 +63,9 @@ constructor dialog {} {
 
 	label $w.desc.loc_l -text [mc "Location:"]
 	set w_loc $w.desc.loc_t
-	location_input $w_loc @location remote
+	set location_op "remote"
+	if {$is_reg} { set location_op "reg" }
+	location_input $w_loc @location $location_op
 	grid $w.desc.loc_l $w_loc -sticky we -padx {0 5}
 
 	grid columnconfigure $w.desc 1 -weight 1
@@ -78,6 +94,18 @@ constructor dialog {} {
 	grid columnconfigure $w.action 1 -weight 1
 	pack $w.action -anchor nw -fill x -pady 5 -padx 5
 
+	if {$is_reg} {
+		focus $w_loc
+		set matcher [regsub -all %s "$repo_config(locator.repo.template)" "(.*)"]
+		set origin willnevermatch
+		catch { set origin $repo_config(remote.origin.url) }
+		if {![regexp $matcher $origin xx base_name]} {
+			error_popup "This repository is not based on a repo.or.cz project; you need to register your project manually."
+			destroy $w
+			return
+		}
+	}
+
 	bind $w <Visibility> [cb _visible]
 	bind $w <Key-Escape> [list destroy $w]
 	bind $w <Key-Return> [cb _add]\;break
@@ -160,6 +188,10 @@ method _add {} {
 			[mc "Setting up the %s (at %s)" $name $location]]
 
 		lappend cmds [list exec git push -v --all $name]
+		if {$is_reg} {
+			global _locator_input
+			start_browser "http://repo.or.cz/m/regproj.cgi?fork=$base_name;LOC_i1=$_locator_input"
+		}
 		console::chain $c $cmds
 	}
 	none {
diff --git a/git-gui/lib/transport.tcl b/git-gui/lib/transport.tcl
index 277e6b8..b80d526 100644
--- a/git-gui/lib/transport.tcl
+++ b/git-gui/lib/transport.tcl
@@ -62,6 +62,12 @@ proc location_input {widget urlvar op} {
 		return 0
 	}
 
+	set state "normal"
+	if {$op == "reg"} {
+		set state "disabled"
+		set op "remote"
+	}
+
 	if {[catch {set default_locator $repo_config(gui.${op}locator)}]} {
 		set default_locator [lindex $all_locators 0]
 	}
@@ -75,6 +81,7 @@ proc location_input {widget urlvar op} {
 
 	frame $widget
 	eval tk_optionMenu $widget.l _locator_template $all_locators
+	$widget.l configure -state $state
 	entry $widget.s \
 		-borderwidth 1 \
 		-relief sunken \
-- 
tg: (2735999..) t/git-gui/remote-publish (depends on: git-gui/remotes git-gui/locators git-gui/web-browse t/git-gui/remote-fetch)

Re: [PATCH 3/3] [FYI]git-gui: repo.or.cz-ish fork integration

[Andreas Ericsson]

pasky@suse.cz wrote:

[ a lot of stuff as an attachment ]

FWIW, I thoroughly like this idea and I'm very excited to see how
it'll work in op5's development environment.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [PATCH 0/3] [RFC] Support for publishing projects at central site

[Peter Krefting]

Hi!

pasky@suse.cz:

> This is not really meant for as-is application, of course, but more
> to see if people think it is good idea to have this kind of
> functionality in git-gui at all and how generic it should be. This
> mini-series depends on pretty much all the other patches I have
> submitted tonight.

As long as it is easy to implement the server-side back-end needed to
automatically accept projects that you publish through this hook, then
this is something that would really help out in this conext.

I currently need to perform some "magic" on the server-side to set up
new projects, it would be nice if all the people using it have to do is
to select a menu option saying "publish". Preferrably through the git
protocol, so that I don't have to set up ssh on people's machines
(working in a Windows environment here, so all central repositories are
set up to use the git protocol for both pull and push).


How do you envision discovering the location to publish to? Some kind
of automatic configuration option would be nice. Perhaps be able to
point git gui at some magic URI that would download an XML (or text)
file describing the central server, perhaps?

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

Re: [PATCH 0/3] [RFC] Support for publishing projects at central site

[Petr Baudis]

Hi!

On Thu, Sep 25, 2008 at 09:56:18AM +0100, Peter Krefting wrote:
> pasky@suse.cz:
> 
> > This is not really meant for as-is application, of course, but more
> > to see if people think it is good idea to have this kind of
> > functionality in git-gui at all and how generic it should be. This
> > mini-series depends on pretty much all the other patches I have
> > submitted tonight.
> 
> As long as it is easy to implement the server-side back-end needed to
> automatically accept projects that you publish through this hook, then
> this is something that would really help out in this conext.

Well, the example URL points to a Girocco script - Girocco is cleaned up
and modernized version of the repo.or.cz duct tape, that should be easy
to reconfigure for any kind of deployment and then simply make
install-able. But any kind of CGI script can be in principle hooked up
to this, so you can just write short shell thing that will do the magic
and then

	echo -e 'Content-type: text/plain\n\nRegistration succeeded!'

> I currently need to perform some "magic" on the server-side to set up
> new projects, it would be nice if all the people using it have to do is
> to select a menu option saying "publish". Preferrably through the git
> protocol, so that I don't have to set up ssh on people's machines
> (working in a Windows environment here, so all central repositories are
> set up to use the git protocol for both pull and push).

Which protocol do you use does not really matter, just set up the
locators right (or don't use them if you don't want to). I ended up
using samba exports mapped to Windows drives, but just using the git
protocol might make more sense in many scenarios.

> How do you envision discovering the location to publish to? Some kind
> of automatic configuration option would be nice. Perhaps be able to
> point git gui at some magic URI that would download an XML (or text)
> file describing the central server, perhaps?

I provide customized MSysGit package with tweaked installer and with
custom /etc/gitconfig. I think in these deployments there is either this
possibility or the machines are centrally administrated so the sysadmin
can adjust /etc/gitconfigs.

-- 
				Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.