git/Makefile, branch gitgui-0.7.5

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

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

git-gui: Gracefully handle bad TCL_PATH at compile time

2007-05-17T22:10:26Z

Petr Baudis pointed out the main git.git repository's Makefile dies now if git-gui 0.7.0-rc1 or later is being used and TCL_PATH was not set to a working tclsh program path. This breaks people who may have a working build configuration today and suddenly upgrade to the latest git release. The tclIndex is required for git-gui to load its associated lib files, but using the Tcl auto_load procedure to source only the files we need is a performance optimization. We can emulate the auto_load by just source'ing every file in that directory, assuming we source class.tcl first to initialize our crude class system. Signed-off-by: Shawn O. Pearce

git-gui: Define a simple class/method system

2007-05-09T01:38:54Z

As most of the git-gui interface is based upon "meta-widgets" that need to carry around a good deal of state (e.g. console windows, browser windows, blame viewer) we have a good deal of messy code that tries to store this meta-widget state in global arrays, where keys into the array are formed from a union of a unique "object instance id" and the field name. This is a simple class system for Tcl that allows us to hide much of that mess by making Tcl do what it does best; process strings to manipulate its own code during startup. Each object instance is placed into its own namespace. The namespace is created when the object instance is created and the namespace is destroyed when the object instance is removed from the system. Within that namespace we place variables for each field within the class; these variables can themselves be scalar values or full-blown Tcl arrays. A simple class might be defined as: class map { field data field size 0 constructor {} { return $this } method set {name value} { set data($name) $value incr size } method size {} { return $size } ifdeleted { return 0 } } All fields must be declared before any constructors or methods. This allows our class to generate a list of the fields so it can properly alter the definition of the constructor and method bodies prior to passing them off to Tcl for definition with proc. A field may optionally be given a default/initial value. This can only be done for non-array type fields. Constructors are given full access to all fields of the class, so they can initialize the data values. The default values of fields (if any) are set before the constructor runs, and the implicit local variable $this is initialized to the instance identifier. Methods are given access to fields they actually use in their body. Every method has an implicit "this" argument inserted as its first parameter; callers of methods must be sure they supply this value. Some basic optimization tricks are performed (but not much). We try to only upvar (locally bind) fields that are accessed within a method, but we err on the side of caution and may upvar more than we need to. If a variable is accessed only once within a method and that access is by $foo (read) we avoid the upvar and instead use [set foo] to obtain the value. This is slightly faster as Tcl does not need to lookup the variable twice. We also offer some small syntatic sugar for interacting with Tk and the fileevent callback system in Tcl. If a field (say "foo") is used as "@foo" we insert instead the true global variable name of that variable into the body of the constructor or method. This allows easy binding to Tk textvariable options, e.g.: label $w.title -textvariable @title Proper namespace callbacks can also be setup with the special cb proc that is defined in each namespace. [cb _foo a] will invoke the method _foo in the current namespace, passing it $this as the first (implied) parameter and a as the second parameter. This makes it very simple to connect an object instance to a -command option for a Tk widget or to a fileevent readable or writable for a file channel. Signed-off-by: Shawn O. Pearce

git-gui: Refactor into multiple files to save my sanity

2007-05-08T03:35:48Z

I'm finding it difficult to work with a 6,000+ line Tcl script and not go insane while looking for a particular block of code. Since most of the program is organized into different units of functionality and not all users will need all units immediately on startup we can improve things by splitting procs out into multiple files and let auto_load handle things for us. This should help not only to better organize the source, but it may also improve startup times for some users as the Tcl parser does not need to read as much script before it can show the UI. In many cases the user can avoid reading at least half of git-gui now. Unfortunately we now need a library directory in our runtime location. This is currently assumed to be $(sharedir)/git-gui/lib and its expected that the Makefile invoker will setup some sort of reasonable sharedir value for us, or let us assume its going to be $(gitexecdir)/../share. We now also require a tclsh (in TCL_PATH) to just run the Makefile, as we use tclsh to generate the tclIndex for our lib directory. I'm hoping this is not an unncessary burden on end-users who are building from source. I haven't really made any functionality changes here, this is just a huge migration of code from one file to many smaller files. All of the new changes are to setup the library path and install the library files. Signed-off-by: Shawn O. Pearce

git-gui: Track our own embedded values and rebuild when they change

2007-05-02T17:06:11Z

Like core-Git we now track the values that we embed into our shell script wrapper, and we "recompile" that wrapper if they are changed. This concept was lifted from git.git's Makefile, where a similar thing was done by Eygene Ryabinkin. Too bad it wasn't just done here in git-gui from the beginning, as the git.git Makefile support for GIT-GUI-VARS was really just because git-gui doesn't do it on its own. Signed-off-by: Shawn O. Pearce

git-gui: Honor TCLTK_PATH if supplied

2007-04-17T17:16:14Z

Mimick what we do for gitk. Since you do have a source file, git-gui.sh, which is separate from the target, it should be much easier in git-gui's Makefile. Signed-off-by: Junio C Hamano Signed-off-by: Shawn O. Pearce