Starting git-gui without any parameters display an error message instead
of a usage message:

Error in startup script: child process exited abnormally
    while executing
"close $fd"
    (procedure "load_all_heads" line 11)
    invoked from within
"load_all_heads"
    invoked from within
"if {[is_enabled transport]} {
        load_all_remotes
        load_all_heads

        populate_branch_menu
        populate_fetch_menu
        populate_push_menu
}"

mfg Martin K

Starting it with no parameters (`git-gui` or `git gui`) should
work just fine.  I do this all of the time on Mac OS X and Windows,

According to this backtrace, we were trying to startup the UI
and load the branches, but:

  git for-each-ref --format=%(refname) refs/heads

returned a non-zero exit code or something else with it went wrong.
Is this maybe a brand new repository?  This is most certainly a bug
in git-gui, but I'd like to understand more about the environment
so I can track it down.

-- 
Shawn.
-

My fault, I had only a too old GIT core (1.4.1) in my path.
With the current version, the problem disapears.

Some notes about using git-gui: 

* Fetching over ssh results in an empty dialog. The password prompt is
only shown in the terminal window, which is likly to be hidden by the
the main window of git-gui.

* It there any reason, why tags are not included in the list of possible
merge sources in Merge/Local Merge?

It only needs one additional line in do_local_merge:
         set cmd [list git for-each-ref]
         lappend cmd {--format=%(objectname) %(refname)}
         lappend cmd refs/heads
         lappend cmd refs/remotes
+        lappend cmd refs/tags
         set fr_fd [open "| $cmd" r]

mfg Martin K

Yea, I figured (much later) it was something like that.  I still
think there is a bug in git-gui, namely not telling you that it
requires Git 1.5.x or later if it finds out the 'git' its invoking
is older than that.  I'll probably patch it tonight, but it won't

This is a "feature".  I only use git-gui + ssh with an ssh-agent
and public key authentication, so I never get password prompts.
Unfortunately Tcl does not permit me to setup bi-directional pipes
to a process (heck, I can't get both stdout and stderr except by
going through cat!), and even if it does, I think ssh would demand
the tty to get the password, thereby bypassing my pipe anyway.

Basically I don't know how to improve this.  If someone has a bright

I just didn't consider it.  The way I use git-gui for merges, I never
merge tags.  But its obviously valid in plain Git.  I'll add it.

-- 
Shawn.
-

Well, there are two way:

1) SSH_ASKPASS (see ssh(1))
    If ssh needs a passphrase, it will read the passphrase from the
    current terminal if it was run from a terminal.  If ssh does not
    have a terminal associated with it but DISPLAY and SSH_ASKPASS
    are set, it will execute the program specified by SSH_ASKPASS
    and open an X11 window to read the passphrase.  This is particu-
    larly useful when calling ssh from a .Xsession or related
    script.  (Note that on some machines it may be necessary to
    redirect the input from /dev/null to make this work.)

This require, that a password helper is installed. One implementation
is part of every linux distribution (openssh-askpass-gnome).

2) Simulate user (like http://websvn.kde.org/tags/KDE/3.4.3/kdebase/kioslave/fish/fish.cpp?rev=467549&vie...)

This requires opening a pty and running ssh on the slave of
it. Additionally it requires some logic to determine, what type of
input ssh requires.

I tried to implement the second way in a C program once. The interpretion
of the ssh output is difficult, but I got it working, but after a system upgrade,
the logic was not working any more. So I would avoid this.

mfg Martin K

I had written a Tk based SSH_ASKPASS helper not to long ago,
and hoped it would work here.  It doesn't work on Cygwin for
anything except ssh-agent.  I'm not sure why.  I haven't tested

Yea, that's a difficult one, and very error prone...

-- 
Shawn.
-

This is now pushed to repo.or.cz.  It probably won't show up in
git.git for at least a few weeks.  I want to push through some
more features (especially around the blame UI) in git-gui before
I bother Junio with another git-gui merge.  Besides, Git 1.5.0
(including git-gui 0.6.0.1) just shipped.  :)

It turned out to be slightly more difficult than just adding
refs/tags, as %(objectname) would be the name of the annotated tag,
and we need the commit name to match against rev-list output.  So I
had to extend the for-each-ref call to also include %(*objectname).

-- 
Shawn.
-

I'm missing the possibility to base a new branch on a tag.
The following adds a tag drop down to the new branch dialog:

--- git-gui.sh  2007-02-14 08:51:38.025781229 +0000
+++ git-gui     2007-02-14 10:50:13.618870598 +0000
@@ -1916,11 +1916,25 @@
        return [lsort -unique $all_trackings]
 }

+proc load_all_tags {} {
+       set all_tags [list]
+       set fd [open "| git for-each-ref --format=%(refname) refs/tags" r]
+       while {[gets $fd line] > 0} {
+               if {![regsub ^refs/tags/ $line {} name]} continue
+               lappend all_tags $name
+       }
+       close $fd
+
+       return [lsort $all_tags]
+}
+
+
 proc do_create_branch_action {w} {
        global all_heads null_sha1 repo_config
        global create_branch_checkout create_branch_revtype
        global create_branch_head create_branch_trackinghead
        global create_branch_name create_branch_revexp
+        global create_branch_tag

        set newbranch $create_branch_name
        if {$newbranch eq {}
@@ -1959,6 +1973,7 @@
        switch -- $create_branch_revtype {
        head {set rev $create_branch_head}
        tracking {set rev $create_branch_trackinghead}
+       tag {set rev $create_branch_tag}
        expression {set rev $create_branch_revexp}
        }
        if {[catch {set cmt [git rev-parse --verify "${rev}^0"]}]} {
@@ -2015,6 +2030,7 @@
        global create_branch_checkout create_branch_revtype
        global create_branch_head create_branch_trackinghead
        global create_branch_name create_branch_revexp
+        global create_branch_tag

        set w .branch_editor
        toplevel $w
@@ -2078,6 +2094,19 @@
                        $all_trackings
                grid $w.from.tracking_r $w.from.tracking_m -sticky w
        }
+       set all_tags [load_all_tags]
+       if {$all_tags ne {}} {
+               set create_branch_tag [lindex $all_tags 0]
+               radiobutton $w.from.tag_r \
+                       -text {Tag:} \
+              ...
[ message continues ]

Yea, again, laziness on my part.  :-) You could enter the tag name
in the SHA-1 expression field, but having it as a picklist may

Unfortunately this patch has severe whitespace damage.  All of the

The indentation does not line up here.  All of the existing context
lines were indented with just one tab, until the whitespace damage
noted above.

-- 
Shawn.
-

This time, the white spaces/tabs should be correct:

--- git-gui.sh	2007-02-14 09:51:38.025781229 +0100
+++ git-gui	2007-02-15 06:53:40.262295256 +0100
@@ -1916,11 +1916,25 @@
 	return [lsort -unique $all_trackings]
 }
 
+proc load_all_tags {} {
+	set all_tags [list]
+	set fd [open "| git for-each-ref --format=%(refname) refs/tags" r]
+	while {[gets $fd line] > 0} {
+		if {![regsub ^refs/tags/ $line {} name]} continue
+		lappend all_tags $name
+	}
+	close $fd
+
+	return [lsort $all_tags]
+}
+
+
 proc do_create_branch_action {w} {
 	global all_heads null_sha1 repo_config
 	global create_branch_checkout create_branch_revtype
 	global create_branch_head create_branch_trackinghead
 	global create_branch_name create_branch_revexp
+	global create_branch_tag
 
 	set newbranch $create_branch_name
 	if {$newbranch eq {}
@@ -1959,6 +1973,7 @@
 	switch -- $create_branch_revtype {
 	head {set rev $create_branch_head}
 	tracking {set rev $create_branch_trackinghead}
+	tag {set rev $create_branch_tag}
 	expression {set rev $create_branch_revexp}
 	}
 	if {[catch {set cmt [git rev-parse --verify "${rev}^0"]}]} {
@@ -2015,6 +2030,7 @@
 	global create_branch_checkout create_branch_revtype
 	global create_branch_head create_branch_trackinghead
 	global create_branch_name create_branch_revexp
+	global create_branch_tag
 
 	set w .branch_editor
 	toplevel $w
@@ -2078,6 +2094,19 @@
 			$all_trackings
 		grid $w.from.tracking_r $w.from.tracking_m -sticky w
 	}
+	set all_tags [load_all_tags]
+	if {$all_tags ne {}} {
+		set create_branch_tag [lindex $all_tags 0]
+		radiobutton $w.from.tag_r \
+			-text {Tag:} \
+			-value tag \
+			-variable create_branch_revtype \
+			-font font_ui
+		eval tk_optionMenu $w.from.tag_m \
+			create_branch_tag \
+			$all_tags
+		grid $w.from.tag_r $w.from.tag_m -sticky w
+	}
 	radiobutton $w.from.exp_r \
 		-text {Revision Expression:} \
 		-value expression \

mfg Martin K

Thanks, that applied cleanly.

Except the radio button for Tag isn't selected if you make a
selection from the tag picklist.  This was easily fixed by adding a
trace to the variable, like the trace already setup for the branch
and tracking branch menus:

diff --git a/git-gui.sh b/git-gui.sh
index 1c3de80..9ce5a3b 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2018,6 +2018,8 @@ trace add variable create_branch_head write \
 	[list radio_selector create_branch_revtype head]
 trace add variable create_branch_trackinghead write \
 	[list radio_selector create_branch_revtype tracking]
+trace add variable create_branch_tag write \
+	[list radio_selector create_branch_revtype tag]
 
 trace add variable delete_branch_head write \
 	[list radio_selector delete_branch_checktype head]

I applied your patch along with the new trace above, and have pushed
it out as the following:

commit 101e3ae7a6b041aa86505bfd3e8b901f1dc245c3
Author: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Date:   Thu Feb 15 01:28:34 2007 -0500

    git-gui: Create new branches from a tag.
    
    I'm missing the possibility to base a new branch on a tag.
    The following adds a tag drop down to the new branch dialog.
    
    Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
    Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

-- 
Shawn.
-