git/Makefile, branch gitgui-0.8.4

git-gui: Provide 'uninstall' Makefile target to undo an installation

2007-09-14T00:02:39Z

Several users have requested a "make uninstall" target be provided in the stock git-gui Makefile so that they can undo an install if git-gui goes to the wrong place during the initial install, or if they are unhappy with the tool and want to remove it from their system. We currently assume that the complete set of files we need to delete are those defined by our Makefile and current source directory. This could differ from what the user actually has installed if they installed one version then attempt to use another to perform the uninstall. Right now I'm just going to say that is "pilot error". Users should uninstall git-gui using the same version of source that they used to make the installation. Perhaps in the future we could read tclIndex and base our uninstall decisions on its contents. Signed-off-by: Shawn O. Pearce

git-gui: Avoid use of libdir in Makefile

2007-09-09T09:03:12Z

Dmitry V. Levin pointed out that on GNU linux libdir is often used in Makefiles to mean "/usr/lib" or "/usr/lib64", a directory that is meant to hold platform-specific binary files. Using a different libdir meaning here in git-gui's Makefile breaks idomatic expressions like rpm specifile "make libdir=%_libdir". Originally I asked that the git.git Makefile undefine libdir before it calls git-gui's own Makefile but it turns out this is very hard to do, if not impossible. Renaming our libdir to gg_libdir resolves this case with a minimum amount of fuss on our part. Signed-off-by: Shawn O. Pearce

Merge branch 'maint'

2007-06-27T04:36:38Z

* maint: git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack git-gui: Don't nice git blame on MSYS as nice is not supported git-gui: Don't require $DISPLAY just to get --version

git-gui: Don't require $DISPLAY just to get --version

2007-06-22T05:10:12Z

Junio asked that we don't force the user to have a valid X11 server configured in $DISPLAY just to obtain the output of `git gui version`. This makes sense, the user may be an automated tool that is running without an X server available to it, such as a build script or other sort of package management system. Or it might just be a user working in a non-GUI environment and wondering "what version of git-gui do I have installed?". Tcl has a lot of warts, but one of its better ones is that a comment can be continued to the next line by escaping the LF that would have ended the comment using a backslash-LF sequence. In the past we have used this trick to escape away the 'exec wish' that is actually a Bourne shell script and keep Tcl from executing it. I'm using that feature here to comment out the Bourne shell script and hide it from the Tcl engine. Except now our Bourne shell script is a few lines long and checks to see if it should print the version, or not. Signed-off-by: Shawn O. Pearce

Merge branch 'maint'

2007-06-21T03:27:08Z

* maint: git-gui: Bind Tab/Shift-Tab to cycle between panes in blame git-gui: Correctly install to /usr/bin on Cygwin

git-gui: Quiet our installation process

2007-06-21T03:26:57Z

Alex Riesen wanted a quieter installation process for git and its contained git-gui. His earlier patch to do this failed to work properly when V=1, and didn't really give a great indication of what the installation was doing. These rules are a little bit on the messy side, as each of our install actions is composed of at least two variables, but in the V=1 case the text is identical to what we had before, while in the non-V=1 case we use some more complex rules to show the interesting details, and hide the less interesting bits. We now can also set QUIET= (nothing) to see the rules that are used when V= (nothing), so we can debug those too if we have to. This is actually a side-effect of how we insert the @ into the rules we use for the "lists of things", like our builtins or our library files. Signed-off-by: Shawn O. Pearce

git-gui: Correctly install to /usr/bin on Cygwin

2007-06-21T03:22:49Z

Mark Levedahl noted that installation on Cygwin to /usr/bin can cause problems with the automatic guessing of our library location. The problem is that installation to /usr/bin means we actually have: /usr/bin = c:\cygwin\bin /usr/share = c:\cygwin\usr\share So git-gui guesses that its library should be found within the c:\cygwin\share directory, as that is where it should be relative to the script itself in c:\cygwin\bin. In my first version of this patch I tried to use `cygpath` to resolve /usr/bin and /usr/share to test that they were in the same relative locations, but that didn't work out correctly as we were actually testing /usr/share against itself, so it always was equal, and we always used relative paths. So my original solution was quite wrong. Mark suggested we just always disable relative behavior on Cygwin, because of the complexity of the mount mapping problem, so that's all I'm doing. Signed-off-by: Shawn O. Pearce

Revert "Make the installation target of git-gui a little less chatty"

2007-06-03T01:01:29Z

This reverts commit c289f6fa1f8642a5caf728ef8ff87afd5718cd99. Junio pointed out that Alex's change breaks in some cases, like when V=1, and is more verbose than it should be even if that worked. I'm backing it out and redoing it. Signed-off-by: Shawn O. Pearce

Make the installation target of git-gui a little less chatty

2007-06-02T03:08:29Z

Signed-off-by: Alex Riesen Signed-off-by: Shawn O. Pearce

git-gui: Guess our share/git-gui/lib path at runtime if possible

2007-05-27T04:03:37Z

Johannes Sixt asked me to try to avoid embedding the runtime location of git-gui's library directory in the executable script. Not embedding it helps the MinGW to be relocatable to another directory should a user wish to install the programs in a directory other than the location the packager wanted them to be installed into. Most of this is a hack. We try to determine if the path of our master git-gui script will be able to locate the lib by ../share/git-gui/lib. This should be true if $(gitexecdir) and $(libdir) have the same prefix. If they do then we defer the assignment of $(libdir) until runtime, and we get it from $argv0 rather than embedding it into the script itself. Signed-off-by: Shawn O. Pearce