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.
From: Thomas Glanzmann <hidden> Date: 2016-06-15 22:43:21
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
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 <redacted>
---
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(-)
From: Brian Downing <hidden> Date: 2016-06-15 22:43:22
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
From: Brian Downing <hidden> Date: 2016-06-15 22:43:22
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
From: Jason Sewall <hidden> Date: 2016-06-15 22:43:22
On 7/17/07, Brian Downing [off-list ref] 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
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
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:22
Jason Sewall [off-list ref] wrote:
On 7/17/07, Brian Downing [off-list ref] wrote:
quoted
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.
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:22
Julian Phillips [off-list ref] wrote:
quoted
'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.
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:22
Brian Downing [off-list ref] 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.
From: Martin Langhoff <hidden> Date: 2016-06-15 22:43:22
On 7/17/07, Shawn O. Pearce [off-list ref] 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
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:22
Martin Langhoff [off-list ref] wrote:
On 7/17/07, Shawn O. Pearce [off-list ref] wrote:
quoted
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.
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.