Skip to main content

Browse the archive

swh:1:snp:6df5a50b8107b6bbe1e51d0239d816a7503c536a
sort by:
Revision Author Date Message Commit Date
b9e7efb Shawn O. Pearce 17 May 2007, 22:01:50 UTC git-gui: Gracefully handle bad TCL_PATH at compile time 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 <spearce@spearce.org> 17 May 2007, 22:10:26 UTC
d6da71a Shawn O. Pearce 10 May 2007, 21:54:45 UTC git gui 0.7.0 Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 May 2007, 21:54:45 UTC
6b3d8b9 Shawn O. Pearce 09 May 2007, 22:35:04 UTC git-gui: Paperbag fix blame in subdirectory Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 10 May 2007, 21:53:34 UTC
76486bb Shawn O. Pearce 09 May 2007, 04:48:27 UTC git-gui: Format author/committer times in ISO format This is a simple change to match what gitk does when it shows a commit; we format using ISO dates (yyyy-mm-dd HH:MM:SS). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 May 2007, 04:48:27 UTC
0511798 Shawn O. Pearce 09 May 2007, 04:36:25 UTC git-gui: Cleanup minor nits in blame code We can use [list ...] rather than "", especially when we are talking about values as then they are properly escaped if necessary. Small nit, but probably not a huge deal as the only data being inlined here is Tk paths. Some of the lines in the parser code were longer than 80 characters wide, and they actually were all the same value on the end part of the line. Rather than keeping the mess copied-and-pasted around we can set the last argument into a local variable and reuse it many times. The commit display code was also rather difficult to read on an 80 character wide terminal, so I'm moving it all into a double quoted string that is easier to read. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 May 2007, 04:36:25 UTC
a0db0d6 Shawn O. Pearce 09 May 2007, 02:48:47 UTC git-gui: Generate blame on uncommitted working tree file If the user doesn't give us a revision parameter to our blame subcommand then we can generate blame against the working tree file by passing the file path off to blame with the --contents argument. In this case we cannot obtain the contents of the file from the ODB; instead we must obtain the contents by reading the working directory file as-is. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 May 2007, 02:48:47 UTC
3e45ee1 Shawn O. Pearce 09 May 2007, 02:36:01 UTC git-gui: Smarter command line parsing for browser, blame The browser subcommand now optionally accepts a single revision argument; if no revision argument is supplied then we use the current branch as the tree to browse. This is very common, so its a nice option. Our blame subcommand now tries to perform the same assumptions as the command line git-blame; both the revision and the file are optional. We assume the argument is a filename if the file exists in the working directory, otherwise we assume the argument is a revision name. A -- can be supplied between the two to force parsing, or before the filename to force it to be a filename. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 May 2007, 02:36:01 UTC
c612785 Shawn O. Pearce 09 May 2007, 01:58:25 UTC git-gui: Use prefix if blame is run in a subdirectory I think it was Andy Parkins who pointed out that git gui blame HEAD f does not work if f is in a subdirectory and we are currently running git-gui within that subdirectory. This is happening because we did not take the user's prefix into account when we computed the file path in the repository. We now assume the prefix as returned by rev-parse --show-prefix is valid and we use that during the command line blame subcommand when we apply the parameters. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 May 2007, 01:58:25 UTC
685caf9 Shawn O. Pearce 09 May 2007, 01:33:14 UTC git-gui: Convert blame to the "class" way of doing things Our blame viewer code has historically been a mess simply because the data for multiple viewers was all crammed into a single pair of Tcl arrays. This made the code hard to read and even harder to maintain. Now that we have a slightly better way of tracking the data for our "meta-widgets" we can make use of it here in the blame viewer to cleanup the code and make it easier to work with long term. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 May 2007, 01:38:55 UTC
28bf928 Shawn O. Pearce 09 May 2007, 01:31:31 UTC git-gui: Don't attempt to inline array reads in methods If a variable reference to a field is to an array, and it is the only reference to that field in that method we cannot make it an inlined [set foo] call as the regexp was converting the Tcl code wrong. We were producing "[set foo](x)" for "$foo(x)", and that isn't valid Tcl when foo is an array. So we just punt if the only occurance has a ( after it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 May 2007, 01:38:54 UTC
c74b6c6 Shawn O. Pearce 09 May 2007, 00:33:47 UTC git-gui: Convert browser, console to "class" format Now that we have a slightly easier method of working with per-widget data we should make use of that technique in our browser and console meta-widgets, as both have a decent amount of information that they store on a per-widget basis and our current approach of handling it is difficult to follow. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 May 2007, 01:38:54 UTC
1f07c4e Shawn O. Pearce 08 May 2007, 23:54:05 UTC git-gui: Define a simple class/method system 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 <spearce@spearce.org> 09 May 2007, 01:38:54 UTC
cc1f83f Shawn O. Pearce 09 May 2007, 01:38:46 UTC git-gui: Allow shift-{k,j} to select a range of branches to merge I found it useful to be able to use j/k (vi-like keys) to move up and down the list of branches to merge and shift-j/k to do the selection, much as shift-up/down (arrow keys) would alter the selection. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 May 2007, 01:38:46 UTC
f0bc498 Shawn O. Pearce 08 May 2007, 14:42:16 UTC Merge branch 'maint' * maint: git-gui: Call changes "Staged" and "Unstaged" in file list titles. 08 May 2007, 14:42:16 UTC
a1a4975 Johannes Sixt 08 May 2007, 11:33:06 UTC git-gui: Call changes "Staged" and "Unstaged" in file list titles. All menu entries talk about "staging" and "unstaging" changes, but the titles of the file lists use different wording, which may confuse newcomers. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 May 2007, 14:35:58 UTC
ebcaada Shawn O. Pearce 05 May 2007, 06:28:41 UTC git-gui: Use vi-like keys in merge dialog Since we support vi-like keys for scrolling in other UI contexts we can easily do so here too. Tk's handy little `event generate' makes this a lot easier than I thought it would be. We may want to go back and fix some of the other vi-like bindings to redirect to the arrow and pageup/pagedown keys, rather than running the view changes directly. I've bound 'v' to visualize, as this is a somewhat common thing to want to do in the merge dialog. Control (or Command) Return is also bound to start the merge, much as it is bound in the main window to activate the commit. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 May 2007, 03:35:53 UTC
1fc4ba8 Shawn O. Pearce 03 May 2007, 22:21:39 UTC git-gui: Include commit id/subject in merge choices When merging branches using our local merge feature it can be handy to know the first few digits of the commit the ref points at as well as the short description of the branch name. Unfortunately I'm unable to use three listboxes in a row, as Tcl freaks out and refuses to let me have a selection in more than one of them at any given point in time. So instead we use a fixed width font in the existing listbox and organize the data into three columns. Not nearly as nice looking, but users can continue to use the listbox's features. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 May 2007, 03:35:52 UTC
349f92e Shawn O. Pearce 02 May 2007, 18:25:22 UTC git-gui: Show all possible branches for merge Johannes Sixt pointed out that git-gui was randomly selecting which branch (or tag!) it will show in the merge dialog when more than one ref points at the same commit. This can be a problem for the user if they want to merge a branch, but the ref that git-gui selected to display was actually a tag that points at the commit at the tip of that branch. Since the user is looking for the branch, and not the tag, its confusing to not find it, and worse, merging the tag causes git-merge to generate a different message than if the branch was selected. While I am in here and am messing around I have changed the for-each-ref usage to take advantage of its --tcl formatting, and to fetch the subject line of the commit (or tag) we are looking at. This way we could present the subject line in the UI to the user, given them an even better chance to select the correct branch. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 May 2007, 03:35:52 UTC
a6c9b08 Shawn O. Pearce 02 May 2007, 17:56:27 UTC git-gui: Move merge support into a namespace Like the console procs I have moved the code related to merge support into their own namespace, so that they are isolated from the rest of the world. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 May 2007, 03:35:51 UTC
60aa065 Shawn O. Pearce 01 May 2007, 19:51:09 UTC git-gui: Allow vi keys to scroll the diff/blame regions Users who are used to vi and recent versions of gitk may want to scroll the diff region using vi style keybindings. Since these aren't bound to anything else and that widget does not accept focus for data input, we can easily support that too. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 May 2007, 03:35:51 UTC
a35d65d Shawn O. Pearce 01 May 2007, 06:59:53 UTC git-gui: Move console procs into their own namespace To help modularize git-gui better I'm isolating the code and variables required to handle our little console windows into their own namespace. This way we can say console::new rather than new_console, and the hidden internal procs to create the window and read data from our filehandle are off in their own private little land, where most users don't see them. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 May 2007, 03:35:50 UTC
f522c9b Shawn O. Pearce 08 May 2007, 03:35:48 UTC git-gui: Refactor into multiple files to save my sanity 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 <spearce@spearce.org> 08 May 2007, 03:35:48 UTC
c6a5e40 Shawn O. Pearce 29 April 2007, 07:02:10 UTC git-gui: Track our own embedded values and rebuild when they change 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 <spearce@spearce.org> 02 May 2007, 17:06:11 UTC
dc6716b Shawn O. Pearce 29 April 2007, 05:54:57 UTC git-gui: Refactor to use our git proc more often Whenever we want to execute a git subcommand from the plumbing layer (and on rare occasion, the more porcelain-ish layer) we tend to use our proc wrapper, just to make the code slightly cleaner at the call sites. I wasn't doing that in a couple of places, so this is a simple cleanup to correct that. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 02 May 2007, 17:06:11 UTC
7416bbc Shawn O. Pearce 29 April 2007, 03:14:08 UTC git-gui: Use option database defaults to set the font Rather than passing "-font font_ui" to every widget that we create we can instead reconfigure the option database for all widget classes to use our font_ui as the default widget font. This way Tk will automatically setup their defaults for us, and we can reduce the size of the application. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 02 May 2007, 17:06:10 UTC
2739291 Shawn O. Pearce 29 April 2007, 02:00:02 UTC git-gui: Cleanup common font handling for font_ui An earlier change tossed these optionMenu font configurations all over the code, when really we can just rename the proc to a hidden internal name and provide our own wrapper to install the font configuration we really want. We also don't need to set these option database entries in all of the procedures that open dialogs; instead we should just set one time, them after we have the font configuration ready for use. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 02 May 2007, 17:06:10 UTC
d45b52b Shawn O. Pearce 29 April 2007, 01:32:27 UTC git-gui: Correct line wrapping for too many branch message Since Tk automatically wraps lines for us in tk_messageBox widgets we don't need to try to wrap them ourselves. Its actually worse that we linewrapped this here in the script, as not all fonts will render this dialog nicely. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 02 May 2007, 17:06:10 UTC
1afd1ec Shawn O. Pearce 29 April 2007, 01:26:27 UTC git-gui: Warn users before making an octopus merge A coworker who was new to git-gui recently tried to make an octopus merge when he did not quite mean to. Unfortunately in his case the branches had file level conflicts and failed to merge with the octopus strategy, and he didn't quite know why this happened. Since most users really don't want to perform an octopus merge this additional safety valve in front of the merge process is a good thing. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 02 May 2007, 17:06:09 UTC
2f1a955 Shawn O. Pearce 29 April 2007, 00:49:22 UTC git-gui: Include the subject in the status bar after commit Now that the command line git-commit has made displaying the subject (first line) of the newly created commit popular we can easily do the same thing here in git-gui, without the ugly part of forking off a child process to obtain that first line. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 02 May 2007, 17:06:09 UTC
3f28f63 Shawn O. Pearce 02 May 2007, 16:45:31 UTC Merge branch 'maint' * maint: git-gui: Allow spaces in path to 'wish' 02 May 2007, 16:45:31 UTC
681bfd5 Shawn O. Pearce 02 May 2007, 16:44:44 UTC git-gui: Allow spaces in path to 'wish' If the path of our wish executable that are running under contains spaces we need to make sure they are escaped in a proper Tcl list, otherwise we are unable to start gitk. Reported by Randal L. Schwartz on #git. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 02 May 2007, 16:44:44 UTC
f20db5f Shawn O. Pearce 24 April 2007, 06:11:40 UTC git-gui: Correctly handle UTF-8 encoded commit messages Uwe Kleine-König discovered git-gui mangled his surname and did not send the proper UTF-8 byte sequence to git-commit-tree when his name appeared in the commit message (e.g. Signed-Off-By line). Turns out this was related to other trouble that I had in the past with trying to use "fconfigure $fd -encoding $enc" to select the stream encoding and let Tcl's IO engine do all of the encoding work for us. Other parts of git-gui were just always setting the file channels to "-encoding binary" and then performing the encoding work themselves using "encoding convertfrom" and "convertto", as that was the only way I could make UTF-8 filenames work properly. I found this same bug in the amend code path, and in the blame display. So its fixed in all three locations (commit creation, reloading message for amend, viewing message in blame). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 24 April 2007, 06:11:40 UTC
845d377 Junio C Hamano 17 April 2007, 10:31:47 UTC git-gui: Honor TCLTK_PATH if supplied 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 <junkio@cox.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 17 April 2007, 17:16:14 UTC
69dd97a Shawn O. Pearce 17 April 2007, 17:15:56 UTC Revert "Allow wish interpreter to be defined with TCLTK_PATH" This reverts commit e2a1bc67d321a0c03737179f331c39a52e7049d7. Junio rightly pointed out this patch doesn't handle the `make install` target very well: Junio C Hamano <junkio@cox.net> writes: > You should never generate new files in the source tree from > 'install' target. Otherwise, the usual pattern of "make" as > yourself and then "make install" as root would not work from a > "root-to-nobody-squashing" NFS mounted source tree to local > filesystem. You should know better than accepting such a patch. 17 April 2007, 17:15:56 UTC
19c8214 Shawn O. Pearce 14 April 2007, 19:10:48 UTC git-gui: Display the directory basename in the title By showing the basename of the directory very early in the title bar I can more easily locate a particular git-gui session when I have 8 open at once and my Windows taskbar is overflowing with items. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 15 April 2007, 04:35:13 UTC
d025d1e Shawn O. Pearce 15 April 2007, 04:34:28 UTC Merge branch 'er/ui' * er/ui: Always bind the return key to the default button Do not break git-gui messages into multiple lines. Improve look-and-feel of the git-gui tool. Teach git-gui to use the user-defined UI font everywhere. Allow wish interpreter to be defined with TCLTK_PATH 15 April 2007, 04:34:28 UTC
f6f2aa3 Shawn O. Pearce 04 April 2007, 16:08:46 UTC git-gui: Brown paper bag fix division by 0 in blame If we generate a blame status string before we have obtained any annotation data at all from the input file, or if the input file is empty, our total_lines will be 0. This causes a division by 0 error when we blindly divide by the 0 to compute the total percentage of lines loaded. Instead we should report 0% done. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 April 2007, 16:08:46 UTC
4372da3 Shawn O. Pearce 04 April 2007, 15:45:33 UTC Always bind the return key to the default button If a dialog/window has a default button registered not every platform associates the return key with that button, but all users do. We have to register the binding of the return key ourselves to make sure the user's expectations of pressing return will activate the default button are met. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 April 2007, 15:45:33 UTC
53a291a Eygene Ryabinkin 27 March 2007, 10:31:55 UTC Do not break git-gui messages into multiple lines. Many git-gui messages were broken into a multiple lines to make good paragraph width. Unfortunately in reality it breaks the paragraph width completely, because the dialog window width does not coincide with the paragraph width created by the current font. Tcl/Tk's standard dialog boxes are breaking the long lines automatically, so it is better to make long lines and let the interpreter do the job. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 April 2007, 15:37:57 UTC
df0cd69 Eygene Ryabinkin 27 March 2007, 10:31:02 UTC Improve look-and-feel of the git-gui tool. Made the default buttons on the dialog active and focused upon the dialog appearence. Bound 'Escape' and 'Return' keys to the dialog dismissal where it was appropriate: mainly for dialogs with only one button and no editable fields, but on console output dialogs as well. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 April 2007, 15:37:56 UTC
3cf0bad Eygene Ryabinkin 27 March 2007, 10:29:08 UTC Teach git-gui to use the user-defined UI font everywhere. Some parts of git-gui were not respecting the default GUI font. Most of them were catched and fixed. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 April 2007, 15:37:56 UTC
e2a1bc6 Eygene Ryabinkin 04 April 2007, 15:31:49 UTC Allow wish interpreter to be defined with TCLTK_PATH Makefile got one external option: - TCLTK_PATH: the path to the Tcl/Tk interpreter. Users (or build wrappers) may set this variable to the location of the wish executable. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 04 April 2007, 15:37:55 UTC
2ec0cb7 Shawn O. Pearce 12 March 2007, 17:26:59 UTC Merge branch 'maint' * maint: git-gui: Allow 'git gui version' outside of a repository git-gui: Revert "git-gui: Display all authors of git-gui." git-gui: Revert "Don't modify CREDITS-FILE if it hasn't changed." git-gui: Allow committing empty merges 12 March 2007, 17:26:59 UTC
756d846 Shawn O. Pearce 12 March 2007, 17:24:10 UTC git-gui: Allow 'git gui version' outside of a repository I got a little surprise one day when I tried to run 'git gui version' outside of a Git repository to determine what version of git-gui was installed on that system. Turns out we were doing the repository check long before we got around to command line argument handling. We now look to see if the only argument we have been given is 'version' or '--version', and if so, print out the version and exit immediately; long before we consider looking at the Git version or working directory. This way users can still get to the git-gui version number even if Git's version cannot be read. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 March 2007, 17:26:06 UTC
bb616dd Shawn O. Pearce 12 March 2007, 17:26:04 UTC git-gui: Revert "git-gui: Display all authors of git-gui." This reverts commit 871f4c97ad7e021d1a0a98c80c5da77fcf70e4af. Too many users have complained about the credits generator in git-gui, so I'm backing the entire thing out. This revert will finish that series. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 March 2007, 17:26:04 UTC
56a7fde Shawn O. Pearce 12 March 2007, 17:25:58 UTC git-gui: Revert "Don't modify CREDITS-FILE if it hasn't changed." This reverts commit 92446aba47b0e0db28f7b858ea387efcca30ab44. Too many users have complained about the credits generator in git-gui, so I'm backing the entire thing out. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 March 2007, 17:25:58 UTC
c7bafad Shawn O. Pearce 12 March 2007, 17:03:47 UTC git-gui: Allow committing empty merges Johannes Sixt noticed that git-gui would not let the user commit a merge created by `git merge -s ours` as the ours strategy does not alter the tree (that is HEAD^1^{tree} = HEAD^{tree} after the merge). The same issue arises from amending such a merge commit. We now permit an empty commit (no changed files) if we are doing a merge commit. Core Git does this with its command line based git-commit tool, so it makes sense for the GUI to do the same. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 March 2007, 17:03:47 UTC
0c3b4aa Alex Riesen 06 March 2007, 23:44:37 UTC git-gui: Support of "make -s" in: do not output anything of the build itself Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 07 March 2007, 00:08:46 UTC
0b5ea16 Shawn O. Pearce 06 March 2007, 07:13:23 UTC git-gui: Make 'make' quieter by default To fit nicely into the output of the git.git project's own quieter Makefile, we want to make the git-gui Makefile nice and quiet too. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 March 2007, 07:13:23 UTC
c3e8a0a Shawn O. Pearce 01 March 2007, 19:37:34 UTC git-gui: Remove unnecessary /dev/null redirection. Git 1.5.0 and later no longer output useless messages to standard error when making the initial (or what looks to be) commit of a repository. Since /dev/null does not exist on Windows in the MinGW environment we can't redirect there anyway. Since Git does not output anymore, I'm removing the redirection. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 01 March 2007, 19:37:34 UTC
51bd9d7 Shawn O. Pearce 26 February 2007, 16:47:14 UTC git-gui: Don't create empty (same tree as parent) commits. Mark Levedahl noticed that git-gui will let you create an empty normal (non-merge) commit if the file state in the index is out of whack. The case Mark was looking at was with the new autoCRLF feature in git enabled and is actually somewhat difficult to create. I found a different way to create an empty commit: turn on the Trust File Modifications flag, touch a file, rescan, then move the file into the "Changes To Be Committed" list without looking at the file's diff. This makes git-gui think there are files staged for commit, yet the update-index call did nothing other than refresh the stat information for the affected file. In this case git-gui allowed the user to make a commit that did not actually change anything in the repository. Creating empty commits is usually a pointless operation; rarely does it record useful information. More often than not an empty commit is actually an indication that the user did not properly update their index prior to commit. We should help the user out by detecting this possible mistake and guiding them through it, rather than blindly recording it. After we get the new tree name back from write-tree we compare it to the parent commit's tree; if they are the same string and this is a normal (non-merge, non-amend) commit then something fishy is going on. The user is making an empty commit, but they most likely don't want to do that. We now pop an informational dialog and start a rescan, aborting the commit. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 February 2007, 16:47:14 UTC
fd234df Shawn O. Pearce 26 February 2007, 16:22:10 UTC git-gui: Add Reset to the Branch menu. cehteh on #git noticed that there was no way to perform a reset --hard from within git-gui. When I pointed out this was Merge->Abort Merge cehteh said this is not very understandable, and that most users would never guess to try that option unless they were actually in a merge. So Branch->Reset is now also a way to cause a reset --hard from within the UI. Right now the confirmation dialog is the same as the one used in Merge->Abort Merge. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 February 2007, 16:22:10 UTC
9b28a8b Shawn O. Pearce 26 February 2007, 16:17:11 UTC git-gui: Relocate the menu/transport menu code. This code doesn't belong down in the main window UI creation, its really part of the menu system and probably should be located with it. I'm moving it because I could not find the code when I was looking for it earlier today, as it was not where I expected it to be found. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 26 February 2007, 16:17:11 UTC
92446ab Junio C Hamano 25 February 2007, 07:18:11 UTC Don't modify CREDITS-FILE if it hasn't changed. We should always avoid rewriting a built file during `make install` if nothing has changed since `make all`. This is to help support the typical installation process of compiling a package as yourself, then installing it as root. Forcing CREDITS-FILE to be always be rebuilt in the Makefile means that CREDITS-GEN needs to check for a change and only update CREDITS-FILE if the file content actually differs. After all, content is king in Git. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 25 February 2007, 07:18:26 UTC
9811937 Shawn O. Pearce 21 February 2007, 06:33:59 UTC git-gui: Don't crash in citool mode on initial commit. Attempting to use `git citool` to create an initial commit caused git-gui to crash with a Tcl error as it tried to add the newly born branch to the non-existant branch menu. Moving this code to after the normal commit cleanup logic resolves the issue, as we only have a branch menu if we are not in singlecommit mode. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 February 2007, 06:33:59 UTC
7391b2e Shawn O. Pearce 21 February 2007, 06:29:05 UTC git-gui: Remove TODO list. I'm apparently not very good at keeping my own TODO file current. I its also somewhat strange to keep the TODO list as part of the software branch, as its meta-information that is not directly related to the code. I'm pulling the TODO list from git-gui and moving it into a seperate branch. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 February 2007, 06:29:05 UTC
c0f7a6c Shawn O. Pearce 21 February 2007, 06:24:57 UTC git-gui: Include browser in our usage message. Now that the 'browser' subcommand can be used to startup the tree browser, it should be listed as a possible subcommand option in our usage message. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 February 2007, 06:24:57 UTC
019f42a Shawn O. Pearce 19 February 2007, 02:08:04 UTC git-gui: Change summary of git-gui. Since git-gui does more than create commits, it is unfair to call it "a commit creation tool". Instead lets just call it a graphical user interface. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 February 2007, 05:11:02 UTC
871f4c9 Shawn O. Pearce 19 February 2007, 02:06:48 UTC git-gui: Display all authors of git-gui. Now that git-gui has been released to the public as part of Git 1.5.0 I am starting to see some work from other people beyond myself and Paul. Consequently the copyright for git-gui is not strictly the two of us anymore, and these others deserve to have some credit given to them. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 February 2007, 05:11:01 UTC
ee40599 Shawn O. Pearce 19 February 2007, 00:06:09 UTC git-gui: Use mixed path for docs on Cygwin. The Firefox browser requires that a URL use / to delimit directories. This is instead of \, as \ gets escaped by the browser into its hex escape code and then relative URLs are incorrectly resolved, Firefox no longer sees the directories for what they are. Since we are handing the browser a true URL, we better use the standard / for directories. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 February 2007, 05:11:01 UTC
372ef95 Shawn O. Pearce 18 February 2007, 07:12:32 UTC git-gui: Correct crash when saving options in blame mode. Martin Waitz noticed that git-gui crashed while saving the user's options out if the application was started in blame mode. This was caused by the do_save_config procedure invoking reshow_diff incase the number of context lines was modified by the user. Because we bypassed main window UI setup to enter blame mode we did not set many of the globals which were accessed by reshow_diff, and reading unset variables is an error in Tcl. Aside from moving the globals to be set earlier, I also modified reshow_diff to not invoke clear_diff if there is no path currently in the diff viewer. This way reshow_diff does not crash when in blame mode due to the $ui_diff command not being defined. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 18 February 2007, 07:12:32 UTC
b90d479 Shawn O. Pearce 16 February 2007, 05:24:03 UTC git-gui: Expose the browser as a subcommand. Some users may find being able to browse around an arbitrary branch to be handy, so we now expose our graphical browser through `git gui browse <committish>`. Yes, I'm being somewhat lazy and making the user give us the name of the branch to browse. They can always enter HEAD. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 16 February 2007, 05:24:03 UTC
101e3ae Martin Koegler 15 February 2007, 06:28:34 UTC git-gui: Create new branches from a tag. I'm missing the possibility to base a new branch on a tag. The following adds a tag drop down to the new branch dialog. Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 15 February 2007, 06:34:40 UTC
26370f7 Shawn O. Pearce 14 February 2007, 06:55:16 UTC git-gui: Prefer version file over git-describe. Some distributions are using Git for part of their package management system, but unpack Git's own source code for delivery from the .tar.gz. This means that when we walk up the directory tree with git-describe to locate a Git repository, the repository we find is for the distribution and *not* for git-gui. Consequently any tag we might find there is bogus and does not apply to us. In this case the version file should always exist and be readable, as the packager is working from the released .tar.gz sources. So we should always favor the version file over anything git-describe guess for us. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 February 2007, 06:55:16 UTC
ed3adde Shawn O. Pearce 14 February 2007, 05:28:00 UTC git-gui: Print version on the console. Like `git version`, `git gui version` (or `git gui --version`) shows the version of git-gui, in case the user needs to know this, without looking at it in the GUI about dialog. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 February 2007, 05:28:00 UTC
5ac58f5 Shawn O. Pearce 14 February 2007, 05:10:20 UTC git-gui: More consistently display the application name. I started to find it confusing that git-gui would refer to itself as git-citool when it was started through the citool hardlink, or with the citool subcommand. What was especially confusing was the options dialog and the about dialog, as both seemed to imply they were somehow different from the git-gui versions. In actuality there is no difference at all. Now we just call our options menu item 'Options...' (skipping the application name) and our About dialog now always shows git-gui within the short description (above the copyleft notice) and in the version field. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 February 2007, 05:10:20 UTC
cdf6e08 Shawn O. Pearce 14 February 2007, 04:43:48 UTC git-gui: Permit merging tags into the current branch. It was pointed out on the git mailing list by Martin Koegler that we did not show tags as possible things to merge into the current branch. They actually are, and core Git's Grand Unified Merge Driver will accept them just like any other commit. So our merge dialog now requests all refs/heads, refs/remotes and refs/tags named refs and attempts to match them against the commits not in HEAD. One complicating factor here is that we must use the %(*objectname) field when talking about an annotated tag, as they will not appear in the output of rev-list. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 February 2007, 04:43:48 UTC
54acdd9 Shawn O. Pearce 14 February 2007, 04:15:25 UTC git-gui: Basic version check to ensure git 1.5.0 or later is used. This is a very crude (but hopefully effective) check against the `git` executable found in our PATH. Some of the subcommands and options that git-gui requires to be present to operate were created during the 1.5.0 development cycle, so 1.5 is the minimum version of git that we can expect to support. There actually are early releases of 1.5 (e.g. 1.5.0-rc0) that don't have everything we expect (like `blame --incremental`) but these are purely academic at this point. 1.5.0 final was tagged and released just a few hours ago. The release candidates will (hopefully) fade into the dark quickly. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 February 2007, 04:15:25 UTC
8134722 Shawn O. Pearce 13 February 2007, 03:48:56 UTC git-gui: Refactor 'exec git subcmd' idiom. As we frequently need to execute a Git subcommand and obtain its returned output we are making heavy use of [exec git foo] to run foo. As I'm concerned about possibly needing to carry environment data through a shell on Cygwin for at least some subcommands, I'm migrating all current calls to a new git proc. This actually makes the code look cleaner too, as we aren't saying 'exec git' everywhere. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 14 February 2007, 02:32:52 UTC
022fef3 Andy Parkins 13 February 2007, 15:26:16 UTC git-gui: fix typo in GIT-VERSION-GEN, "/dev/null" not "/devnull" Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 13 February 2007, 15:35:58 UTC
fdf6cfc Shawn O. Pearce 12 February 2007, 22:45:21 UTC git-gui: Change base version to 0.6. This is the start of the 0.6 series of git-gui. I'm calling it 0.6 (rather than any other value) as I already had a private tag on one system based on 0.5, and that tag is quite a bit behind this version. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 February 2007, 22:45:21 UTC
07d082b Shawn O. Pearce 12 February 2007, 22:05:10 UTC git-gui: Guess our version accurately as a subproject. When we are included as a subproject, such as how git.git carries us, we want to retain our own version number and not the version number assigned by git.git's own tags. Consequently we need to locate the correct tag which applies to our tree content and its commit lineage. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 February 2007, 22:05:10 UTC
6a6459b Shawn O. Pearce 12 February 2007, 21:38:29 UTC git-gui: Handle gitgui tags in version gen. I've decided to use gitgui-0.5 as the format for tags in the git-gui repository. The prefix of gitgui was chosen here to make its namespace different from the namespace used by git itself, allowing developers to pull both tag namespaces into the same repository. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 February 2007, 21:38:29 UTC
5d643cd Shawn O. Pearce 12 February 2007, 21:14:44 UTC git-gui: Generate a version file on demand. Because git-gui is being shipped as a subproject of the main Git project and will often have a different lifecycle than the main Git project, we should ship our own version number in the release tarball rather than relying on the main Git version file. Git's master Makefile will invoke our own with the target dist-version, asking us to save off our GITGUI_VERSION value into our own version file, so that our GIT-VERSION-GEN script can recover it at build time. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 February 2007, 21:14:44 UTC
7e81d4e Shawn O. Pearce 12 February 2007, 21:12:04 UTC git-gui: Rename GIT_VERSION to GITGUI_VERSION. Now that the decision has been made to treat git-gui as a subproject, rather than merging it directly into git, we should use a different substitution for our version value to avoid any possible confusion. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 February 2007, 21:12:04 UTC
663e7cf Shawn O. Pearce 12 February 2007, 20:37:50 UTC git-gui: Allow gitexecdir, INSTALL to be set by the caller. When used as a subproject within git.git our Makefile must honor the gitexecdir which git.git's Makefile is passing down to us, ensuring that we install our executables into the libexec chosen by the end-user or packager. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 February 2007, 20:37:50 UTC
0960f7d Shawn O. Pearce 11 February 2007, 22:19:38 UTC git-gui: Stop deleting gitk preferences. Now that git 1.5.0 and later contains a version of gitk that uses correct geometry on Windows platforms, even if ~/.gitk exists, we should not delete the user's ~/.gitk to work around the bug. It is downright mean to remove a user's preferences for another app. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 11 February 2007, 22:19:38 UTC
d585e78 Shawn O. Pearce 09 February 2007, 07:28:32 UTC git-gui: Focus into blame panels on Mac OS. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 07:28:32 UTC
486ef52 Shawn O. Pearce 09 February 2007, 06:59:38 UTC git-gui: Improve annotated file display. Rather than trying to mark the background color of the line numbers to show which lines have annotated data loaded, we now show a ruler between the line numbers and the file data. This ruler is just 1 character wide and its background color is set to grey to denote which lines have annotation ready. I had to make this change as I kept loosing the annotation marker when a line was no longer colored as part of the current selection. We now color the lines blamed on the current commit in yellow, the lines in the commit which came after (descendant) in red (hotter, less tested) and the lines in the commit before (ancestor) in blue (cooler, better tested). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 06:59:38 UTC
1351ba1 Shawn O. Pearce 09 February 2007, 03:41:51 UTC git-gui: Jump to the first annotation block as soon as its available. To help clue users into the fact that annotation data arrives incrementally, and that they should try to locate the region they want while the tool is running, we jump to the first line of the first annotation if the user has not already clicked on a line they are interested in and if the window is still looking at the very top of the file. Since it takes a second (at least on my PowerBook) to even generate the first annotation for git-gui.sh, the user should have plenty of time to adjust the scrollbar or click on a line even before we get that first annotation record in, which allows the user to bypass our automatic jumping. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 03:41:51 UTC
6910ae8 Shawn O. Pearce 09 February 2007, 02:39:27 UTC git-gui: Redesign the display of annotated files. Using 180 columns worth of screen space to display just 20 columns of file data and 160 columns worth of annotation information is not practically useful. Users need/want to see the file data, and have the anotation associated with it displayed in a detail pane only when they have focused on a particular region of the file. Now our file viewer has a small 10-line high pane below the file which shows the commit message for the commit this line was blamed on. The columns have all been removed, except the current line number column as that has some real value when trying to locate an interesting block. To keep the user entertained we have a progress meter in the status bar of the viewer which lets them know how many lines have been annotated, and how much has been completed. We use a grey background on the line numbers for lines which we have obtained annotation from, and we color all lines in the current commit with a yellow background, so they stand out when scanning through the file. All other lines are kept with a white background, making the yellow really pop. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 02:39:27 UTC
df6287e Shawn O. Pearce 09 February 2007, 00:53:36 UTC git-gui: Use git-config now over git-repo-config. Now that core Git has "renamed" git-repo-config to git-config, we should do the same. I don't know how long core Git will keep the repo-config command, and since git-gui's userbase is so small and almost entirely on some flavor of 1.5.0-rc2 or later, where the rename has already taken place, it should be OK to rename now. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 00:53:36 UTC
24d2bf2 Shawn O. Pearce 09 February 2007, 00:44:49 UTC git-gui: Relabel the Add All action. One user that I spoke with recently was confused why the 'Add All' button did not add all of his 'Changed But Not Updated' files. The particular files in question were new, and thus not known to Git. Since the 'Add All' routine only updates files which are already tracked, they were not added automatically. I suspect that calling this action 'Add Existing' would be less confusing, so I'm renaming it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 00:44:49 UTC
258871d Shawn O. Pearce 09 February 2007, 00:41:32 UTC git-gui: Select subcommands like git does. If we are invoked as `git-foo`, then we should run the `foo` subcommand, as the user has made some sort of link from `git-foo` to our actual program code. So we should honor their request. If we are invoked as `git-gui foo`, the user has not made a link (or did, but is not using it right now) so we should execute the `foo` subcommand. We now can start the single commit UI mode via `git-citool` and also through `git gui citool`. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 00:41:32 UTC
2ebba52 Shawn O. Pearce 09 February 2007, 00:10:52 UTC git-gui: View blame from the command line. Viewing annotated files is one of those tasks that is relatively difficult to do in a simple vt100 terminal emulator. The user really wants to be able to browse through a lot of information, and to interact with it by navigating through revisions. Now users can start our file viewer with annotations by running 'git gui blame commit path', thereby seeing the contents of the given file at the given commit. Right now I am being lazy by not allowing the user to omit the commit name (and have us thus assume HEAD). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 09 February 2007, 00:10:52 UTC
db7f34d Shawn O. Pearce 08 February 2007, 22:47:17 UTC git-gui: Optionally save commit buffer on exit. If the commit area does not exist, don't save the commit message to a file, or the window geometry. The reason I'm doing this is I want to make the main window entirely optional, such as if the user has asked us to show a blame from the command line. In such cases the commit area won't exist and trying to get its text would cause an error. If we are running without the commit message area, we cannot save our window geometry either, as the root window '.' won't be a normal commit window. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 February 2007, 23:14:44 UTC
64a906f Shawn O. Pearce 08 February 2007, 23:10:05 UTC git-gui: Separate transport/branch menus from multicommit. These are now controlled by the transport and branch options, rather than the multicommit option. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 February 2007, 23:10:05 UTC
cf25ddc Shawn O. Pearce 08 February 2007, 23:03:41 UTC git-gui: Refactor single_commit to a proc. This is a minor code cleanup to make working with what used to be the $single_commit flag easier. Its also to better handle various UI configurations, depending on command line parameters given by the user, or perhaps user preferences. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 February 2007, 23:03:41 UTC
42b922f Shawn O. Pearce 08 February 2007, 22:13:51 UTC git-gui: Replace \ with \\ when showing paths. We already replace \n with \\n so that Tk widgets don't start a new display line with part of a file path which is just unlucky enough to contain an LF. But then its confusing to read a path whose name actually contains \n as literal characters. Escaping \ to \\ would make that case display as \\n, clarifying the output. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 February 2007, 22:13:51 UTC
9bccb78 Shawn O. Pearce 08 February 2007, 22:07:59 UTC git-gui: Support keyboard traversal in browser. Users want to navigate the file list shown in our branch browser windows using the keyboard. So we now support basic traversal with the arrow keys: Up/Down: Move the "selection bar" to focus on a different name. Return: Move into the subtree, or open the annotated file. M1-Right: Ditto. M1-Up: Move to the parent tree. M1-Left: Ditto. Probably the only feature missing from this is to key a leading part of the file name and jump directly to that file (or subtree). This change did require a bit of refactoring, to pull the navigation logic out of the mouse click procedure and into more generic routines which can also be used in bindings. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 February 2007, 22:07:59 UTC
63faf4d Shawn O. Pearce 08 February 2007, 20:59:39 UTC git-gui: Update known branches during rescan. If the user has created (or deleted) a branch through an external tool, and uses Rescan, they probably are trying to make git-gui update to show their newly created branch. So now we load all known heads and update the branch menu during any rescan operation, just in-case the set of known branches was modified. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 February 2007, 20:59:39 UTC
37f1db8 Shawn O. Pearce 29 January 2007, 11:56:00 UTC git-gui: Assign background colors to each blame hunk. To help the user visually see which lines are associated with each other in the file we attempt to sign a unique background color to each commit and then render all text associated with that commit using that color. This works out OK for a file which has very few commits in it; but most files don't have that property. What we really need to do is look at what colors are used by our neighboring commits (if known yet) and pick a color which does not conflict with our neighbor. If we have run out of colors then we should force our neighbor to recolor too. Yes, its the graph coloring problem. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 11:56:00 UTC
747c0cf Shawn O. Pearce 29 January 2007, 11:23:12 UTC git-gui: Use a grid layout for the blame viewer. Using a panedwindow to display the blame viewer's individual columns just doesn't make sense. Most of the important data fits within the columns we have allocated, and those that don't the leading part fits and that's good enough. There are just too many columns within this viewer to let the user sanely control individual column widths. This change shouldn't really be an issue for most git-gui users as their displays should be large enough to accept this massive dump of data. We now also have a properly working horizontal scrollbar for the current file data area. This makes it easier to get away with a narrow window when screen space is limited, as you can still scroll around within the file content. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 11:23:12 UTC
e7fb6c6 Shawn O. Pearce 29 January 2007, 10:51:49 UTC git-gui: Install column headers in blame viewer. I started to get confused about what each column meant in the blame viewer, and I'm the guy who wrote the code! So now git-gui hints to the user about what each column is by drawing headers at the top. Unfortunately this meant I had to use those dreaded frame objects which seem to cause so much pain on Windows. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 10:51:49 UTC
915616e Shawn O. Pearce 29 January 2007, 10:33:27 UTC git-gui: Display original filename and line number in blame. When we annotate a file and show its line data, we're already asking for copy and movement detection (-M -C). This costs extra time, but gives extra data. Since we are asking for the extra data we really should show it to the user. Now the blame UI has two additional columns, one for the original filename (in the case of a move/copy between files) and one for the original line number of the current line of code. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 10:33:27 UTC
8f6c07b Shawn O. Pearce 29 January 2007, 08:09:28 UTC git-gui: Correctly handle spaces in filepaths. Anytime are about to open a pipe on what may be user data we need to make sure the value is escaped correctly into a Tcl list, so that the executed subprocess will receive the right arguments. For the most part we were already doing this correctly, but a handful of locations did not. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 08:09:28 UTC
463ca37 Shawn O. Pearce 29 January 2007, 08:03:29 UTC git-gui: Use -M and -C when running blame. Since we run blame incrementally in the background we might as well get as much data as we can from the file. Adding -M and -C definately makes it take longer to compute the revision annotations, but since they are streamed in and updated as they are discovered we'll get recent data almost immediately anyway. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 08:03:29 UTC
db45378 Shawn O. Pearce 29 January 2007, 07:56:07 UTC git-gui: Allow users to edit user.name, user.email from options. Users may need to be able to alter their user.name or user.email configuration settings. If they are mostly a git-gui user they should be able to view/set these important values from within the git-gui environment, rather than needing to edit a raw text file on their local filesystem. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 07:56:07 UTC
c94dd1c Shawn O. Pearce 29 January 2007, 07:52:06 UTC git-gui: Display the current branch name in browsers. Rather than using HEAD for the current branch, use the actual name of the current branch in the browser. This way the user knows what a browser is browsing if they open up different browsers while on different branches. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 07:52:06 UTC
3eddda9 Shawn O. Pearce 29 January 2007, 07:50:10 UTC git-gui: Improve the icons used in the browser display. Real icons which seem to indicate going up to the parent (an up arrow) and a subdirectory (an open folder). Files are now drawn with the file_mod icon, like a modified file is. This just looks better as it is more consistent with the rest of our UI. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 29 January 2007, 07:50:10 UTC
back to top