Problem running git-gui

Problem running git-gui

[Julian Phillips]

I have a machine on which git was installed from a tarball created by 
running git-archive on master (so a 1.5.3ish version).

When I try running git-gui I get an error message:

'Error in startup script: expected version number but got "1.5.3.GIT"'

followed by what I assume is a code snippet where it failed (I wouldn't 
know tcl if it hit me with a large brick).

Is this expected? driver error? or maybe a bug?

-- 
Julian

  ---
mixed emotions:
 	Watching a bus-load of lawyers plunge off a cliff.
 	With five empty seats.

Re: Problem running git-gui

[Thomas Glanzmann]

Hello Julian,

> 'Error in startup script: expected version number but got "1.5.3.GIT"'

I get the same error. However it works with released versions of git:

	(faui04a) [~] git gui
	Error in startup script: invalid command name "git-version"
	while executing
	"git-version >= 1.5.3"
	(in namespace eval "::blame" script line 36)
	invoked from within
	"namespace eval $class $body"
	(procedure "class" line 16)
	invoked from within
	"class blame {

	image create photo ::blame::img_back_arrow -data {R0lGODlhGAAYAIUAAPwCBEzKXFTSZIz+nGzmhGzqfGTidIT+nEzGXHTqhGzmfGzifFzadETCVES+VARWDFzWb..."
	(file "/usr/share/git-gui/lib/blame.tcl" line 4)
	invoked from within
	"source [file join $oguilib $p]"
	("foreach" body line 3)
	invoked from within
	"foreach p $idx {
			if {[lsearch -exact $loaded $p] >= 0} continue
			source [file join $oguilib $p]
			lappend loaded $p
		}"
	invoked from within
	"if {$idx ne {}} {
		set loaded [list]
		foreach p $idx {
			if {[lsearch -exact $loaded $p] >= 0} continue
			source [file join $oguilib $p]
			lappend loa..."
	(file "/usr/bin/git-gui" line 98)

it is because "1.5.3.GIT" is not a number I guess.

	Thomas

[PATCH] git-gui: Handle git versions of the form n.n.n.GIT

[Julian Phillips]

The git-gui version check doesn't handle versions of the form
n.n.n.GIT which you can get by installing from an tarball produced by
git-archive.

Without this change you get an error of the form:
'Error in startup script: expected version number but got "1.5.3.GIT"'

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---

> I have a machine on which git was installed from a tarball created by 
> running git-archive on master (so a 1.5.3ish version).
> 
> When I try running git-gui I get an error message:
> 
> 'Error in startup script: expected version number but got "1.5.3.GIT"'
> 
> followed by what I assume is a code snippet where it failed (I wouldn't 
> know tcl if it hit me with a large brick).
> 
> Is this expected? driver error? or maybe a bug?

Well, whichever it is, this seems to fix it for me ... with the proviso that I
still no nothing about tcl.  I am also not sure if it is correct to do the
patch against the git repo?

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

diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 2077261..f8b1f10 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -546,6 +546,7 @@ if {![regsub {^git version } $_git_version {} _git_version]} {
 }
 regsub {\.[0-9]+\.g[0-9a-f]+$} $_git_version {} _git_version
 regsub {\.rc[0-9]+$} $_git_version {} _git_version
+regsub {\.GIT$} $_git_version {} _git_version
 
 proc git-version {args} {
 	global _git_version
-- 
1.5.2.2

Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT

[Brian Downing]

On Tue, Jul 17, 2007 at 10:14:06PM +0100, Julian Phillips wrote:
> The git-gui version check doesn't handle versions of the form
> n.n.n.GIT which you can get by installing from an tarball produced by
> git-archive.
> 
> Without this change you get an error of the form:
> 'Error in startup script: expected version number but got "1.5.3.GIT"'

Can we handle versions with '-dirty' at the end as well, or is this
ill-advised?  For some reason when I build my hacked-up personal debian
packages it usually winds up:

:; git --version
git version 1.5.3.GIT-dirty

and I haven't bothered to find out why.

-bcd

Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT

[Brian Downing]

On Tue, Jul 17, 2007 at 04:40:12PM -0500, Brian Downing wrote:
> Can we handle versions with '-dirty' at the end as well, or is this
> ill-advised?  For some reason when I build my hacked-up personal debian
> packages it usually winds up:
> 
> :; git --version
> git version 1.5.3.GIT-dirty
> 
> and I haven't bothered to find out why.

D'oh, now I know why.  I'm trying git to keep my home directory config
stuff versioned, so GIT-VERSION-GEN, failing to find a .git directory
in my tar export, digs down and finds my home directory one instead.

I take it this means that keeping your home directory under git
/directly/ as I have chosen to do is a bad idea...

-bcd

Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT

[Jason Sewall]

On 7/17/07, Brian Downing <bdowning@lavos.net> wrote:
> I take it this means that keeping your home directory under git
> /directly/ as I have chosen to do is a bad idea...

Interesting, because this is something I've wanted to do - I use
several machines (work, work laptop, home, home laptop) and I'm always
tweaking my various dotfiles... I could really use a way to keep them
all synchronized.

Just out of curiosity, what do you people do?

Jason

Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT

[Shawn O. Pearce]

Jason Sewall <jasonsewall@gmail.com> wrote:
> On 7/17/07, Brian Downing <bdowning@lavos.net> wrote:
> >I take it this means that keeping your home directory under git
> >/directly/ as I have chosen to do is a bad idea...
> 
> Interesting, because this is something I've wanted to do - I use
> several machines (work, work laptop, home, home laptop) and I'm always
> tweaking my various dotfiles... I could really use a way to keep them
> all synchronized.
> 
> Just out of curiosity, what do you people do?

I have a regular git directory in ~/cgwork/HomeDir, with its
associated .git directory in ~/cgwork/HomeDir/.git.  In other
words standard Git repository setup in a location that isn't my
actual home directory.

My dotfiles in ~/ are actually symlinks back to that Git repository.
To update the symlinks I run the script below.  Its pretty simple,
it just merges to directories from the Git repository into my ~/
as dotfiles (the dot-* items) and into my ~/bin (the bin/* items).
So my Git repository looks like this:

  $ git ls-tree --abbrev=4 HEAD
  040000 tree 0d35        common
  040000 tree e033        host-asimov
  040000 tree 21c4        host-spearce-pb15.local
  100755 blob 0f2d        relink.sh

  $ git ls-tree --abbrev=4 HEAD:common/
  040000 tree cc76        bin
  100644 blob 371e        dot-bash_profile
  100644 blob e675        dot-bashrc
  100644 blob 1f0a        dot-gitconfig
  100644 blob 3d02        dot-ldaprc
  100644 blob 1d42        dot-vilerc

  $ git ls-tree --abbrev=4 HEAD:common/bin/
  100755 blob 7322        cherry-kill
  100755 blob 9ed5        fp
  100755 blob 89f2        genbibtex
  100755 blob 68be        newrepo
  100755 blob 3759        tkbibtex

  $ ls -l ~/.bashrc ~/bin/fp
  lrwxr-xr-x   1 spearce  spearce  41 Feb  3 23:05 /Users/spearce/.bashrc -> cgwork/HomeDir-DotFiles/common/dot-bashrc
  lrwxr-xr-x   1 spearce  spearce  40 Feb  3 23:05 /Users/spearce/bin/fp -> ../cgwork/HomeDir-DotFiles/common/bin/fp

Yea, it relies on the fact that I never use `git config --global`,
which apparently I've done recently as the damn thing isn't a symlink
like its supposed to be.  Uggh.  Its the *only* program on my system
that doesn't resolve the symlink and edit the file it points at.

-->--
#!/bin/sh

root=`dirname "$0"`
[ -d "$root" ] || {
	echo "error: Can't locate $0 in filesystem." >&2
	exit 1
}

cd "$root"
root=$(pwd)
root=$(echo "$root" | sed s:^$HOME/::)

if [ "X$HOSTTYPE" = Xpowerpc ]
then
	HOSTNAME=spearce-pb15.local
fi

dot_sources="common/dot-* host-$HOSTNAME/dot-*"
bin_sources="common/bin/* host-$HOSTNAME/bin/*"

echo "Linking from $dot_sources"
for src in $dot_sources
do
	if [ -e "$src" ]
	then
		dot_file=$(basename "$src" | sed s/^dot-/./)

		targ="$root/$src"
		dest="$HOME/$dot_file"

		if [ -L "$dest" ]
		then
			echo " U $dest -> $targ"
			rm -f "$dest"
			ln -s "$targ" "$dest"
			continue
		fi

		if [ ! -e "$dest" ]
		then
			echo " N $dest -> $targ"
			ln -s "$targ" "$dest"
			continue
		fi

		if [ -e "$dest" -a ! -e "$dest.bak" ]
		then
			echo " O $dest -> $targ"
			mv "$dest" "$dest.bak"
			ln -s "$targ" "$dest"
			continue
		fi

		echo " ! $dest -> $targ"
	fi
done
echo "done."

echo
echo "Linking from $bin_sources"
for src in $bin_sources
do
	if [ -e "$src" ]
	then
		bin_file=$(basename "$src")

		case "$root" in
		/*) targ="$root/$src";;
		*)  targ="../$root/$src"
		esac
		dest="$HOME/bin/$bin_file"

		mkdir -p "$HOME/bin"

		if [ -L "$dest" ]
		then
			echo " U $dest -> $targ"
			rm -f "$dest"
			ln -s "$targ" "$dest"
			continue
		fi

		if [ ! -e "$dest" ]
		then
			echo " N $dest -> $targ"
			ln -s "$targ" "$dest"
			continue
		fi

		if [ -e "$dest" -a ! -e "$dest.bak" ]
		then
			echo " O $dest -> $targ"
			mv "$dest" "$dest.bak"
			chmod a-x "$dest.bak"
			ln -s "$targ" "$dest"
			continue
		fi

		echo " ! $dest -> $targ"
	fi
done
echo "done."
-->--

-- 
Shawn.

Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT

[Linus Torvalds]

On Tue, 17 Jul 2007, Brian Downing wrote:
> 
> D'oh, now I know why.  I'm trying git to keep my home directory config
> stuff versioned, so GIT-VERSION-GEN, failing to find a .git directory
> in my tar export, digs down and finds my home directory one instead.

Ok, that's definitely a git misfeature.

I think we could probably add a check something like:

 - once we have found a .git directory by walking up the tree, the 
   directory we actually came _from_ should then be tracked by that git 
   directory.

but I wonder how to do that properly (we would probably need to load the 
index, which we generally don't want to do).

		Linus

Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT

[Shawn O. Pearce]

Brian Downing <bdowning@lavos.net> wrote:
> Can we handle versions with '-dirty' at the end as well, or is this
> ill-advised?  For some reason when I build my hacked-up personal debian
> packages it usually winds up:
> 
> :; git --version
> git version 1.5.3.GIT-dirty
> 
> and I haven't bothered to find out why.

Already fixed.  Please get the latest version of git-gui...

-- 
Shawn.

Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT

[Shawn O. Pearce]

Julian Phillips <julian@quantumfyre.co.uk> wrote:
> > 'Error in startup script: expected version number but got "1.5.3.GIT"'
> > 
> > followed by what I assume is a code snippet where it failed (I wouldn't 
> > know tcl if it hit me with a large brick).
> > 
> > Is this expected? driver error? or maybe a bug?

Bug in git-gui.  *sigh*
 
> Well, whichever it is, this seems to fix it for me ... with the proviso that I
> still no nothing about tcl.  I am also not sure if it is correct to do the
> patch against the git repo?
> 
>  git-gui/git-gui.sh |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)

Many thanks for the fix.  I was about to do this myself but found
your message in my inbox instead.  Happy days.

Fortunately git-am -3 does wonders, and it didn't matter:

  $ git am -s -3 jp
  
  Applying git-gui: Handle git versions of the form n.n.n.GIT
  
  error: git-gui/git-gui.sh: does not exist in index
  Using index info to reconstruct a base tree...
  Falling back to patching base and 3-way merge...
  Renamed git-gui/git-gui.sh => git-gui.sh
  Wrote tree 1909733645c3bd167b1b28a98ee66c0a95f357f1
  Committed: 91464dfb102d6143182d8f312b68486e9dceb103

I've extolled the virtues of -3 and merge-recursive's rename detector
before on the mailing list, for exactly this reason.  Despite the
patch coming in with the wrong path it still applies just fine.

-- 
Shawn.

Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT

[Martin Langhoff]

On 7/17/07, Shawn O. Pearce <spearce@spearce.org> wrote:
>   Applying git-gui: Handle git versions of the form n.n.n.GIT
>

I'm far from an authority on things TCL, but I don't think this patch
should be merged as is. Julian is reporting it as a "fixes my symptom"
patch, and that's barely what it does.

The regex should be more liberal, imho. With this superficial fix:

 - Builds from a dirty tree have a broken git gui

 - Builds from a repo with a nonstandard (local) tagname tagname  have
a broken git gui

cheers,


martin

Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT

[Shawn O. Pearce]

Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 7/17/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> >  Applying git-gui: Handle git versions of the form n.n.n.GIT
> >
> 
> I'm far from an authority on things TCL, but I don't think this patch
> should be merged as is.

Too late, already applied and pushed.  ;-)

> Julian is reporting it as a "fixes my symptom"
> patch, and that's barely what it does.
> 
> The regex should be more liberal, imho. With this superficial fix:

I think we are now cleaning up the Git version as best we can:

  regsub -- {-dirty$} $_git_version {} _git_version
  regsub {\.[0-9]+\.g[0-9a-f]+$} $_git_version {} _git_version
  regsub {\.rc[0-9]+$} $_git_version {} _git_version
  regsub {\.GIT$} $_git_version {} _git_version

The first fixes the -dirty build problem.  The second drops off
the extra information that git-describe throws into the mix when
it generates output for a non-tagged commit.  The third kills the
rc* component if this is a release candidate.  Note that the rc*
killer must come after the git-describe killer, as the rc* part is
actually in the real tag.  The last one fixes the weird case where
the user has somehow bungled his git software distribution so it
cannot generate a git version via git-describe *and* they have no
`version` file in the source code directory.  Such people really
should fix their git.  But anyway we do support it now.

> - Builds from a repo with a nonstandard (local) tagname tagname  have
> a broken git gui

This I cannot do anything about, other than maybe to warn the user
that they are about to run with a version of Git that we cannot
verify and hence we have no idea if git-gui will work correctly,
or fall flat on its face.

I'll add in a confirmation dialog for this case.  That way the
user can make the decision.  User always knows best.

-- 
Shawn.

Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT

[Julian Phillips]

On Tue, 17 Jul 2007, Shawn O. Pearce wrote:

> The first fixes the -dirty build problem.  The second drops off
> the extra information that git-describe throws into the mix when
> it generates output for a non-tagged commit.  The third kills the
> rc* component if this is a release candidate.  Note that the rc*
> killer must come after the git-describe killer, as the rc* part is
> actually in the real tag.  The last one fixes the weird case where
> the user has somehow bungled his git software distribution so it
> cannot generate a git version via git-describe *and* they have no
> `version` file in the source code directory.  Such people really
> should fix their git.  But anyway we do support it now.

Well, I would say that my git is not broken, but simply temporary.  I 
have a machine that is not connected to the internet where I want to run 
git.  Normally I use release tarballs, but at the moment I need the recent 
changes to fast-import, so I am running whatever was master at the time I 
made the tarball.

As soon as 1.5.3 comes out I will be back to using the official releases. 
I just wanted to run git-gui blame (a rather nice tool) to look at what 
the result of my latest test import looked like.  Since I wasn't using git 
for anything other than playing with fast-import, creating a properly 
versioned git seemed like more effort than it was worth.

-- 
Julian

  ---
The major difference between bonds and bond traders is that the bonds will
eventually mature.