* Problem running git-gui
@ 2007-07-17 11:48 Julian Phillips
2007-07-17 12:04 ` Thomas Glanzmann
2007-07-17 21:14 ` [PATCH] git-gui: Handle git versions of the form n.n.n.GIT Julian Phillips
0 siblings, 2 replies; 13+ messages in thread
From: Julian Phillips @ 2007-07-17 11:48 UTC (permalink / raw
To: Shawn O. Pearce; +Cc: git
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Problem running git-gui
2007-07-17 11:48 Problem running git-gui Julian Phillips
@ 2007-07-17 12:04 ` Thomas Glanzmann
2007-07-17 21:14 ` [PATCH] git-gui: Handle git versions of the form n.n.n.GIT Julian Phillips
1 sibling, 0 replies; 13+ messages in thread
From: Thomas Glanzmann @ 2007-07-17 12:04 UTC (permalink / raw
To: Julian Phillips; +Cc: Shawn O. Pearce, git
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
2007-07-17 11:48 Problem running git-gui Julian Phillips
2007-07-17 12:04 ` Thomas Glanzmann
@ 2007-07-17 21:14 ` Julian Phillips
2007-07-17 21:40 ` Brian Downing
2007-07-18 1:51 ` Shawn O. Pearce
1 sibling, 2 replies; 13+ messages in thread
From: Julian Phillips @ 2007-07-17 21:14 UTC (permalink / raw
To: Shawn O. Pearce; +Cc: git
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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
2007-07-17 21:14 ` [PATCH] git-gui: Handle git versions of the form n.n.n.GIT Julian Phillips
@ 2007-07-17 21:40 ` Brian Downing
2007-07-17 21:45 ` Brian Downing
2007-07-18 1:52 ` Shawn O. Pearce
2007-07-18 1:51 ` Shawn O. Pearce
1 sibling, 2 replies; 13+ messages in thread
From: Brian Downing @ 2007-07-17 21:40 UTC (permalink / raw
To: Julian Phillips; +Cc: Shawn O. Pearce, git
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
2007-07-17 21:40 ` Brian Downing
@ 2007-07-17 21:45 ` Brian Downing
2007-07-17 21:49 ` Jason Sewall
2007-07-17 22:34 ` Linus Torvalds
2007-07-18 1:52 ` Shawn O. Pearce
1 sibling, 2 replies; 13+ messages in thread
From: Brian Downing @ 2007-07-17 21:45 UTC (permalink / raw
To: Julian Phillips; +Cc: Shawn O. Pearce, git
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
2007-07-17 21:45 ` Brian Downing
@ 2007-07-17 21:49 ` Jason Sewall
2007-07-18 1:48 ` Shawn O. Pearce
2007-07-17 22:34 ` Linus Torvalds
1 sibling, 1 reply; 13+ messages in thread
From: Jason Sewall @ 2007-07-17 21:49 UTC (permalink / raw
To: Brian Downing; +Cc: Julian Phillips, Shawn O. Pearce, git
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
2007-07-17 21:45 ` Brian Downing
2007-07-17 21:49 ` Jason Sewall
@ 2007-07-17 22:34 ` Linus Torvalds
1 sibling, 0 replies; 13+ messages in thread
From: Linus Torvalds @ 2007-07-17 22:34 UTC (permalink / raw
To: Brian Downing; +Cc: Julian Phillips, Shawn O. Pearce, git
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
2007-07-17 21:49 ` Jason Sewall
@ 2007-07-18 1:48 ` Shawn O. Pearce
0 siblings, 0 replies; 13+ messages in thread
From: Shawn O. Pearce @ 2007-07-18 1:48 UTC (permalink / raw
To: Jason Sewall; +Cc: Brian Downing, Julian Phillips, git
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
2007-07-17 21:14 ` [PATCH] git-gui: Handle git versions of the form n.n.n.GIT Julian Phillips
2007-07-17 21:40 ` Brian Downing
@ 2007-07-18 1:51 ` Shawn O. Pearce
2007-07-18 2:32 ` Martin Langhoff
1 sibling, 1 reply; 13+ messages in thread
From: Shawn O. Pearce @ 2007-07-18 1:51 UTC (permalink / raw
To: Julian Phillips; +Cc: git
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
2007-07-17 21:40 ` Brian Downing
2007-07-17 21:45 ` Brian Downing
@ 2007-07-18 1:52 ` Shawn O. Pearce
1 sibling, 0 replies; 13+ messages in thread
From: Shawn O. Pearce @ 2007-07-18 1:52 UTC (permalink / raw
To: Brian Downing; +Cc: Julian Phillips, git
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
2007-07-18 1:51 ` Shawn O. Pearce
@ 2007-07-18 2:32 ` Martin Langhoff
2007-07-18 2:54 ` Shawn O. Pearce
0 siblings, 1 reply; 13+ messages in thread
From: Martin Langhoff @ 2007-07-18 2:32 UTC (permalink / raw
To: Shawn O. Pearce; +Cc: Julian Phillips, git
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
2007-07-18 2:32 ` Martin Langhoff
@ 2007-07-18 2:54 ` Shawn O. Pearce
2007-07-18 10:10 ` Julian Phillips
0 siblings, 1 reply; 13+ messages in thread
From: Shawn O. Pearce @ 2007-07-18 2:54 UTC (permalink / raw
To: Martin Langhoff; +Cc: Julian Phillips, git
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
2007-07-18 2:54 ` Shawn O. Pearce
@ 2007-07-18 10:10 ` Julian Phillips
0 siblings, 0 replies; 13+ messages in thread
From: Julian Phillips @ 2007-07-18 10:10 UTC (permalink / raw
To: Shawn O. Pearce; +Cc: Martin Langhoff, git
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2007-07-18 10:10 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-07-17 11:48 Problem running git-gui Julian Phillips
2007-07-17 12:04 ` Thomas Glanzmann
2007-07-17 21:14 ` [PATCH] git-gui: Handle git versions of the form n.n.n.GIT Julian Phillips
2007-07-17 21:40 ` Brian Downing
2007-07-17 21:45 ` Brian Downing
2007-07-17 21:49 ` Jason Sewall
2007-07-18 1:48 ` Shawn O. Pearce
2007-07-17 22:34 ` Linus Torvalds
2007-07-18 1:52 ` Shawn O. Pearce
2007-07-18 1:51 ` Shawn O. Pearce
2007-07-18 2:32 ` Martin Langhoff
2007-07-18 2:54 ` Shawn O. Pearce
2007-07-18 10:10 ` Julian Phillips
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).