user/sven/git.git/lib, branch gitgui-0.9.0

Merge branch 'maint'

2007-10-23T22:50:19Z

* maint: git-gui: Make sure we get errors from git-update-index Conflicts: lib/index.tcl

git-gui: Make sure we get errors from git-update-index

2007-10-23T22:49:27Z

I'm seeing a lot of silent failures from git-update-index on Windows and this is leaving the index.lock file intact, which means users are later unable to perform additional operations. When the index is locked behind our back and we are unable to use it we may need to allow the user to delete the index lock and try again. However our UI state is probably not currect as we have assumed that some changes were applied but none of them actually did. A rescan is the easiest (in code anyway) solution to correct our UI to show what the index really has (or doesn't have). Signed-off-by: Shawn O. Pearce

Merge branch 'maint'

2007-10-21T00:43:36Z

* maint: git-gui: Don't display CR within console windows git-gui: Handle progress bars from newer gits git-gui: Correctly report failures from git-write-tree Conflicts: lib/commit.tcl lib/console.tcl

git-gui: Don't display CR within console windows

2007-10-21T00:42:01Z

Git progress bars from tools like git-push and git-fetch use CR to skip back to the start of the current line and redraw it with an updated progress. We were doing this in our Tk widget but had failed to skip the CR, which Tk doesn't draw well. Signed-off-by: Shawn O. Pearce

git-gui: Handle progress bars from newer gits

2007-10-21T00:36:27Z

Post Git 1.5.3 a new style progress bar has been introduced that uses only one line rather than two. The formatting of the completed and total section is also slightly different so we must adjust our regexp to match. Unfortunately both styles are in active use by different versions of Git so we need to look for both. Signed-off-by: Shawn O. Pearce

git-gui: Correctly report failures from git-write-tree

2007-10-20T05:42:01Z

If git-write-tree fails (such as if the index file is currently locked and it wants to write to it) we were not getting the error message as $tree_id was always the empty string so we shortcut through the catch and never got the output from stderr. Signed-off-by: Shawn O. Pearce

git-gui: Collapse $env(HOME) to ~/ in recent repositories on Windows

2007-10-13T03:07:59Z

Apparently native Tcl/Tk on Windows is using \ as the return value from [file separator] but [file normalize] on that same system is using / rather than \ to represent a directory separator. I really think that is nuts, but its what is happening. So we can actually just hardcode our separator to / as all systems we support (Windows, Mac OS X, UNIX) use /. Signed-off-by: Shawn O. Pearce

git-gui: Support cloning Cygwin based work-dirs

2007-10-13T03:07:58Z

If the user tries to clone a Git repository that is actually a workdir of another repository (by way of contrib git-new-workdir) then the contents of .git is a series of Windows .lnk files which Tcl can't read if this is a native Tcl process. To read the real objects directory we need to resolve the link to that location. Signed-off-by: Shawn O. Pearce

git-gui: Use proper Windows shortcuts instead of bat files

2007-10-13T03:07:58Z

On Windows its better to use a shortcut (.lnk file) over a batch script (.bat) as we can specify the icon file for the .lnk and thus have these git specific objects appear on the desktop with that git specific icon file. Unfortunately the authors of Tcl did not bless us with the APIs needed to create shortcuts from within Tcl. But Microsoft did give us Windows Scripting Host which allows us to execute some JavaScript that calls some sort of COM object that can operate on a .lnk file. We now build both Cygwin and non-Cygwin "desktop icons" as proper Windows .lnk files, using the "Start in" property of these files to indicate the working directory of the repository the user wants to launch. Signed-off-by: Shawn O. Pearce

git-gui: Bind n/c/o accelerators in repository chooser

2007-10-13T03:05:59Z

On Windows we need to actually setup binds for the accelerator keys, otherwise the OS doesn't respond to them when the user presses the key combinations. Apparently we automatically get these on Mac OS X when we configure the menu commands, but not on Windows. Signed-off-by: Shawn O. Pearce