Skip to main content

Browse the archive

Staging
v0.5.1
swh:1:snp:c5feb7ee9221a3820c8879e85e8a18470c0b3afa
sort by:
Revision Author Date Message Commit Date
7e508eb Shawn O. Pearce 26 June 2007, 19:27:35 UTC git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack The Tools/Migrate menu option is a hack just for me. Yes, that's right, git-gui has a hidden feature that really only works for me, and the users that I support within my day-job's great firewall. The menu option is not supported outside of that environment. In the past we only enabled Tools/Migrate if our special local script 'gui-miga' existed in the proper location, and if there was a special '.pvcsrc' in the top level of the working directory. This latter test for the '.pvcsrc' file is now failing, as the file was removed from all Git repositories due to changes made to other tooling within the great firewall's realm. I have changed the test to only work on Cygwin, and only if the special 'gui-miga' is present. This works around the configuration changes made recently within the great firewall's realm, but really this entire Tools/Migrate thing should be abstracted out into some sort of plugin system so other users can extend git-gui as they need. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 27 June 2007, 04:35:30 UTC
fffaaba Shawn O. Pearce 27 June 2007, 04:27:13 UTC git-gui: Don't nice git blame on MSYS as nice is not supported Johannes Sixt reported that MinGW/MSYS does not have a nice.exe to drop the priority of a child process when it gets spawned. So we have to avoid trying to start `git blame` through nice when we are on Windows and do not have Cygwin available to us. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 27 June 2007, 04:27:13 UTC
4e817d1 Shawn O. Pearce 22 June 2007, 05:10:12 UTC git-gui: Don't require $DISPLAY just to get --version 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 <spearce@spearce.org> 22 June 2007, 05:10:12 UTC
fb626dc Shawn O. Pearce 12 June 2007, 04:04:30 UTC git-gui: Bind Tab/Shift-Tab to cycle between panes in blame The blame viewer is composed of two different areas, the file area on top and the commit area on the bottom. If users are trying to shift the focus it is probably because they want to shift from one area to the other, so we just setup Tab and Shift-Tab to jump from the one half to the other in a cycle. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 21 June 2007, 03:25:23 UTC
82a2d6b Shawn O. Pearce 19 June 2007, 14:48:09 UTC git-gui: Correctly install to /usr/bin on Cygwin Mark Levedahl <mlevedahl@gmail.com> 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 <spearce@spearce.org> 21 June 2007, 03:22:49 UTC
39fa2a9 Shawn O. Pearce 12 June 2007, 03:52:43 UTC git-gui: Save geometry before the window layout is damaged Because Tk does not assure us the order that it will process children in before it destroys the main toplevel we cannot safely save our geometry data during a "bind . <Destroy>" event binding. The geometry may have already changed as a result of a one or more children being removed from the layout. This was pointed out in gitk by Mark Levedahl, and patched over there by commit b6047c5a8166a71e01c6b63ebbb67c6894d95114. So we now also use "wm protocol . WM_DELETE_WINDOW" to detect when the window is closed by the user, and forward that close event to our main do_quit routine. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 12 June 2007, 03:52:43 UTC
b2f3bb1 Shawn O. Pearce 11 June 2007, 23:39:55 UTC git-gui: Give amend precedence to HEAD over MERGE_MSG Apparently git-commit.sh (the command line commit user interface in core Git) always gives precedence to the prior commit's message if `commit --amend` is used and a $GIT_DIR/MERGE_MSG file also exists. We actually were doing the same here in git-gui, but the amended message got lost if $GIT_DIR/MERGE_MSG already existed because we started a rescan immediately after loading the prior commit's body into the edit buffer. When that happened the rescan found MERGE_MSG existed and replaced the commit message buffer with the contents of that file. This meant the user never saw us pick up the commit message of the prior commit we are about to replace. Johannes Sixt <J.Sixt@eudaptics.com> found this bug in git-gui by running `git cherry-pick -n $someid` and then trying to amend the prior commit in git-gui, thus combining the contents of $someid with the contents of HEAD, and reusing the commit message of HEAD, not $someid. With the recent changes to make cherry-pick use the $GIT_DIR/MERGE_MSG file Johannes saw git-gui pick up the message of $someid, not HEAD. Now we always use HEAD if we are amending. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 11 June 2007, 23:48:41 UTC
615b865 Shawn O. Pearce 11 June 2007, 23:06:10 UTC git-gui: Include 'war on whitespace' fixes from git.git Earlier git.git applied a large "war on whitespace" patch that was created using 'apply --whitespace=strip'. Unfortunately a few of git-gui's own files got caught in the mix and were also cleaned up. That was a6080a0a44d5ead84db3dabbbc80e82df838533d. This patch is needed in git-gui.git to reapply those exact same changes here, otherwise our version generator script is unable to obtain our version number from git-describe when we are hosted in the git.git repository. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 11 June 2007, 23:06:10 UTC
d80ded0 Shawn O. Pearce 08 June 2007, 06:02:48 UTC git-gui: Changed blame header bar background to match main window The main window's diff header bar background switched from orange to gold recently, and I liked the effect it had on readability of the text. Since I wanted the blame viewer to match, here it is. Though this probably should be a user defined color, or at least a constant somewhere that everyone can reference. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 08 June 2007, 06:50:07 UTC
0f32da5 Shawn O. Pearce 06 June 2007, 07:22:22 UTC git-gui: Favor the original annotations over the recent ones Usually when you are looking at blame annotations for a region of a file you are more interested in why something was originally done then why it is here now. This is because most of the time when we get original annotation data we are looking at a simple refactoring performed to better organize code, not to change its semantic meaning or function. Reorganizations are sometimes of interest, but not usually. We now show the original commit data first in the tooltip. This actually looks quite nice as the original commit will usually have an author date prior to the current (aka move/copy) annotation's commit, so the two commits will now tend to appear in chronological order. I also found myself to always be clicking on the line of interest in the file column but I always wanted the original tracking data and not the move/copy data. So I changed our default commit from $asim_data (the simple move/copy annotation) to the more complex $amov_data (the -M -C -C original annotation). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 07:22:22 UTC
949da61 Shawn O. Pearce 06 June 2007, 07:03:16 UTC git-gui: Improve our labeling of blame annotation types It feels wrong to call the -M -C -C annotations "move/copy tracking" as they are actually the original locations. So I'm relabeling the status bar to show "copy/move tracking annotations" for the current file (no -M -C -C) as that set of annotations tells us who put the hunk here (who moved/copied it). I'm now calling the -M -C -C pass "original location annotations" as that's what we're really digging for. I also tried to clarify some of the text in the hover tooltip. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 07:03:52 UTC
5d198d6 Shawn O. Pearce 06 June 2007, 06:53:36 UTC git-gui: Use three colors for the blame viewer background To prevent neighboring lines that are different commits from using the same background color we now use 3 colors and assign them by selecting the color that is not used before or after the line in question. We still color "on the fly" as we receive hunks from git-blame, but we delay our color decisions until we are getting the original location data (the slower -M -C -C pass) as that is usually more fine-grained than the current location data. Credit goes to Martin Waitz for the tri-coloring concept. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 06:53:36 UTC
0dfed77 Shawn O. Pearce 04 June 2007, 08:07:35 UTC git-gui: Jump to original line in blame viewer When the user clicks on a commit link within one of the columns in the blame viewer we now jump them not just to that commit/file pair but also to the line of the original file. This saves the user a lot of time, as they don't need to search through the new file data for the chunk they were previously looking at. We also restore the prior view when the user clicks the back button to return to a pior commit/file pair that they were looking at. Turned out this was quite tricky to get working in Tk. Every time I tried to jump the text widgets to the correct locations by way of the "yview moveto" or "see" subcommands Tk performed the change until the current event finished dispatching, and then reset the views back to 0, making the change never take place. Forcing Tk to run the pending events before we jump the UI resolves the issue. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:52 UTC
383d4e0 Shawn O. Pearce 02 June 2007, 23:03:55 UTC git-gui: Display both commits in our tooltips If we have commit data from both the simple blame and the rename/move tracking blame and they differ than there is a bigger story to tell. We now include data from both commits so that the user can see that this link as moved, who moved it, and where it originated from. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:52 UTC
172c92b Shawn O. Pearce 02 June 2007, 22:21:18 UTC git-gui: Run blame twice on the same file and display both outputs We now perform two passes over any input file given to the blame viewer. Our first pass is a quick "git-blame" with no options, getting the details of how each line arrived into this file. We are specifically ignoring/omitting the rename detection logic as this first pass is to determine why things got into the state they are in. Once the first pass is complete and is displayed in the UI we run a second pass, using the much more CPU intensive "-M -C -C" options to perform extensive rename/movement detection. The output of this second pass is shown in a different column, allowing the user to see for any given line how it got to be, and if it came from somewhere else, where that is. This is actually very instructive when run on our own lib/branch.tcl script. That file grew recently out of a very large block of code in git-gui.sh. The first pass shows when I created that file, while the second pass shows the original commit information. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:51 UTC
debcd0f Shawn O. Pearce 02 June 2007, 21:15:56 UTC git-gui: Display the "Loading annotation..." message in italic If the user clicks on a line region that we haven't yet received an annotation for from git-blame we show them "Loading annotation". But I don't want the user to confuse this loading message with a commit whose first line is "Loading annotation" and think we messed up our display somehow. Since we never use italics for anything else, I'm going with the idea that italic slant can be used to show data is missing/elided out at the time being. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:51 UTC
fc816d7 Shawn O. Pearce 03 June 2007, 03:26:24 UTC git-gui: Rename fields in blame viewer to better descriptions Calling the commit message pane $w_cmit is a tad confusing when we also have the $w_cgrp column that shows the abbreviated SHA-1s. So w_cmit -> w_cviewer, as it is the "commit viewer"; and w_cgrp -> w_amov as it is the "annotated commit + move tracking" column. Also changed line_data -> amov_data, as that list is exactly the results shown in w_amov. Why call the column "move tracking"? Because this column holds data from "git blame -M -C". I'm considering adding an additional column that holds the data from "git blame" without -M/-C, showing who did the copy/move, and when they did it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:51 UTC
c5db65a Shawn O. Pearce 02 June 2007, 20:03:52 UTC git-gui: Label the uncommitted blame history entry If the user runs the blame viewer on a working directory file instead of a specific commit-ish then we have no value for the commit SHA1 or the summary line; this causes the history menu to get an empty entry at the very bottom. We now look for this odd case and call the meny entry "Working Directory". Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:50 UTC
2f85b7e Shawn O. Pearce 02 June 2007, 20:01:43 UTC git-gui: Switch internal blame structure to Tcl lists The Tcl list datatype is significantly faster to work with than the array type, especially if our indexes are a consecutive set of numbers, like say line numbers in a file. This rather large change reorganizes the internal data structure of the blame viewer to use a proper Tcl list for the annotation information about a line. Each line is given its own list within the larger line_data list, where the indexes correspond to various facts about that particular line. The interface does seem to be more responsive this way, with less time required by Tcl to process blame, and to switch to another version of the same file. It could just be a placebo effect, but either way most Tcl experts perfer lists for this type of work over arrays. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:50 UTC
14c4dfd Shawn O. Pearce 02 June 2007, 19:34:52 UTC git-gui: Cleanup redundant column management in blame viewer The code to handle our three different text widgets is a bit on the messy side as we issue the same command on all three widgets one at a time. Adding (or removing) columns from the viewer is messy, as a lot of locations need to have the new column added into the sequence, or removed from it. We also now delete the tags we create for each commit when we switch to display another "commit:path" pair. This way the text viewer doesn't get bogged down with a massive number of tags as we traverse through history. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:50 UTC
c17c175 Shawn O. Pearce 02 June 2007, 19:13:35 UTC git-gui: Better document our blame variables The array variable "order" used to be used to tell us in what order each commit was received in. Recent changes have removed that need for an ordering and the "order" array is now just a boolean 'do we have that commit yet' flag. The colors were moved to fields, so they appear inside of the blame viewer instance. This keeps two different concurrently running blame viewers from stepping on each other's ordering of the colors in group_colors. Most of the other fields were moved around a little bit so that they are organized by major category and value lifespan. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:50 UTC
b611015 Shawn O. Pearce 02 June 2007, 18:45:35 UTC git-gui: Remove unused commit_list from blame viewer This list used to store the commits in the order we received them in. I originally was using it to update the colors of the commit before and the commit after the current commit, but since that interface concept turned out to be horribly ugly and has been removed we no longer need this list. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:49 UTC
81fb7ef Shawn O. Pearce 02 June 2007, 18:41:10 UTC git-gui: Automatically expand the line number column as needed After we finish reading a chunk of data from the file stream we know how many digits we need in the line number column to show the current maximum line number. If our line number column isn't wide enough, we should expand it out to the correct width. Any file over our default allowance of 5 digits (99,999 lines) is so large that the slight UI "glitch" when we widen the column out is trivial compared to the time it will take Git to fully do the annotations. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:49 UTC
375e136 Shawn O. Pearce 02 June 2007, 18:35:44 UTC git-gui: Make the line number column slightly wider in blame Most source code files are under 9,999 lines of text, so using a field width of 5 characters meant that we should have had one char padding on the left edge (because we right-justify the line number). Unfortunately when I added the right margin earlier (when I removed the padding) I ate into the extra character's space, losing the left margin. This put the line numbers too close to the commit column in any file with more than 999 lines in it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:49 UTC
000a106 Shawn O. Pearce 02 June 2007, 18:31:01 UTC git-gui: Use lighter colors in blame view The colors I originally picked out on a Mac OS X system look a tad too dark on a Windows 2000 system; the greys are dark enough to make it difficult to read some lines of text and the green used to highlight the current commit was also difficult to read text on. I also added a third grey to the mix, to try and help some files that wind up with a number of neighboring chunks getting the same colors. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:49 UTC
0632570 Shawn O. Pearce 02 June 2007, 06:55:53 UTC git-gui: Remove unnecessary space between columns in blame viewer On Mac OS X the OS has "features" that like to draw thick black borders around the text field that has focus. This is nice if you want to know where your text is going and are blind as a bat, but it isn't the best thing to have in a table that is being faked through the abuse of Tk text widgets. By setting our takefocus, highlightthickness and padx/y we can get rid of this border and get our text widgets packed right next to each other, with no padding between them. This makes the blame background color smoothly run across the entire line of commit data, line number and file content. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:48 UTC
0eab69a Shawn O. Pearce 02 June 2007, 06:38:26 UTC git-gui: Remove the loaded column from the blame viewer Originally I had placed this loaded column between the line number and the file line data to help users know if a particular line has received annotation data or not yet. This way users would know if the line(s) they were interested in were ready for viewing, or if they still had to wait. It also was an entertaining way for the user to spend their time waiting for git-blame --incremental to compute the complete set of annotations. However it is completely useless now that we show the abbreviated commit SHA-1 and author initials in the leftmost column. That area is empty until we get the annotation data, and as soon as we get it in we display something there, indicating to the user that there is now blame data ready. Further with the tooltips the user is likely to see the data as soon as it comes in, as they are probably not keeping their mouse perfectly still. So I'm removing the field to save screen space for more useful things, like file content. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:48 UTC
b55a243 Shawn O. Pearce 02 June 2007, 04:09:55 UTC git-gui: Clip the commit summaries in the blame history menu Some commit lines can get really long when users enter a lot of text without linewrapping (for example). Rather than letting the menu get out of control in terms of width we clip the summary to the first 50+ characters. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:48 UTC
08dda17 Shawn O. Pearce 02 June 2007, 03:48:18 UTC git-gui: Use a label instead of a button for the back button Apparently Tk on Mac OS X won't draw a button with an image using a transparent background. Instead it draws the button using some sort of 3D effect, even though I asked for no relief and no border. The background is also not our orange that we expected it to be. Earlier I had tried this same trick on Windows and it draws the same way as the button did, so I'm going to switch to the label as that seems to be more portable. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:48 UTC
79c50bf Shawn O. Pearce 02 June 2007, 01:59:29 UTC git-gui: Show original filename in blame tooltip If we have two commits right next to each other in the final file and they were kept as different blocks in the leftmost column then its probably because the original filename was different. To help the user know where they are digging into when they click on that link we now show the original file in the tooltip, but to save space we do so only if the original file is not the same as the file we are currently viewing. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:47 UTC
669fbc3 Shawn O. Pearce 02 June 2007, 01:54:06 UTC git-gui: Combine blame groups only if commit and filename match Consecutive chunks of a file could come from the same commit, but have different original file names. Previously we would have put them into a single group, but then the hyperlink would jump to only one of the files, and the other would not be accessible. Now we can get to the other file too. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:47 UTC
22c6769 Shawn O. Pearce 02 June 2007, 01:47:12 UTC git-gui: Allow digging through history in blame viewer gitweb has long had a feature where the user can click on any commit the blame display and go visit that commit's information page. From the user could go get the blame display for the file they are tracking, and try to digg through the history of any part of the code they are interested in seeing. We now offer somewhat similiar functionality in git-gui. The 4 digit commit abreviation in the first column of our blame view is now offered as a hyperlink if the commit isn't the one we are now viewing the blame output for (as there is no point in linking back to yourself). Clicking on that link will stop the current blame engine (if still running), push the new target commit onto the history stack, and restart the blame viewer at that commit, using the "original file name" as supplied by git-blame for that chunk of the output. Users can navigate back to a version they had been viewing before by way of a back button, which offers the prior commits in a popup menu displayed right below the back button. I'm always showing the menu here as the cost of switching between views is very high; you don't want to jump to a commit you are not interested in looking at again. During switches we throw away all data except the cached commit data, as that is relatively small compared to most source files and their annotation marks. Unfortunately throwing this per-file data away in Tcl seems to take some time; I probably should move the line indexed arrays to proper lists and use [lindex] rather than the array lookup (usually lists are faster). We now start the git-blame process using "nice", so that its priority will drop hopefully below our own. If I don't do this the blame engine gets a lot of CPU under Windows 2000 and the git-gui user interface is almost non-responsive, even though Tcl is just sitting there waiting for events. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:47 UTC
982cf98 Shawn O. Pearce 01 June 2007, 22:29:20 UTC git-gui: Display a progress bar during blame annotation gathering Computing the blame records for a large file with a long project history can take git a while to run; traditionally we have shown a little meter in the status area of our blame viewer that lets the user know how many lines have been finished, and how far we are through the process. Usually such progress indicators are drawn with a little progress bar in the window, where the bar shows how much has been completed and hides itself when the process is complete. I'm using a very simple hack to do that: draw a canvas with a filled rectangle. Of course the time remaining has absolutely no relationship to the progress meter. It could take very little time for git-blame to get the first 90% of the file, and then it could take many times that to get the remaining 10%. So the progress meter doesn't really have any sort of assurances that it relates to the true progress of the work. But in practice on some ugly history it does seem to hold a reasonable indicator to the completion status. Besides, its amusing to watch and that keeps the user from realizing git is being somewhat slow. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:47 UTC
d0b741d Shawn O. Pearce 01 June 2007, 21:55:43 UTC git-gui: Allow the user to control the blame/commit split point At one point I tried to present the blame viewer to an audience of people on a 640 by 480 pixel LCD projector. This did not work at all as the top area (the file data) was taking up all of the screen realestate and the split point was not adjustable by the user. In general locking the user into a specific ratio of display is just not user friendly. So we now place a split pane control into the middle of our blame window, so the user can adjust it to their current needs. If the window increases (or decreases) in height we assign the difference to the file data area, as that is generally the area of the window that users are trying to see more of when they grow the window. Unfortunately there appears to be a bug in the "pack" layout manager in Tcl/Tk 8.4.1. The status bar and the lower commit pane was being squashed if the window decreased in height. I think the pack manager was just not decreasing the size of the panedwindow slave properly if the main window shrank. Switching to the "grid" layout manager fixes the problem, but is slightly uglier setup code. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:46 UTC
223475a Shawn O. Pearce 01 June 2007, 20:10:56 UTC git-gui: Show author initials in blame groups Frequently when I'm looking at blocks of code in the blame viewer I want to know who is the culprit, or who I should be praising for a job well done. The tooltips nicely show this if I mouse over a block, but it doesn't work to get this detail at a glance. Since we don't use the leftmost commit column for anything after the first line within a commit group I'm now tossing the author's initials into that field, right justified. It is quite clearly not a SHA-1 number as we always show the SHA-1 in lowercase, while we explicitly select only the uppercase characters from an author's name field, and only those that are following whitespace. I'm using initials here over anything else as they are quite commonly unique within small development teams. The leading part of the email address field was out for some of the teams I work with, as there the email addresses are all of the form "Givenname.Surname@initech.com". That will never fit into the 4 characters available. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:46 UTC
ddc1fa8 Shawn O. Pearce 01 June 2007, 19:31:01 UTC git-gui: Space the commit group continuation out in blame view The | in the continued lines of the same commit group as not easily seen on the left edge; putting a single space in front of the pipe makes it slightly more visually appealing to me as I can follow the line down through the group to the next commit marker. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:46 UTC
b5a4122 Shawn O. Pearce 01 June 2007, 07:34:00 UTC git-gui: Cleanup minor style nit Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:46 UTC
8154e1a Shawn O. Pearce 01 June 2007, 07:33:28 UTC git-gui: Remove unnecessary reshow of blamed commit Because we no longer redraw colors every time we select a particular commit there is no need to redraw the screen after we get a new commit in from blame --incremental. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:45 UTC
74fe898 Shawn O. Pearce 01 June 2007, 07:19:27 UTC git-gui: Highlight the blame commit header from everything else The selected commit's blame header is now drawn in green, using the same background color that is shown in the main file content viewer. The result is a much better looking commit pane, as we use bold for header "keys" and proportional width fonts for the stuff that doesn't need to be fixed width to maintain its formatting. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:45 UTC
41bf23d Shawn O. Pearce 01 June 2007, 07:01:45 UTC git-gui: Display tooltips in blame viewer When the mouse is over a particular line and we have blame data for that line, but its not the active commit, we should show the user information about that commit like who the author was and what the subject (first line) was. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:45 UTC
37ebc93 Shawn O. Pearce 01 June 2007, 06:59:21 UTC git-gui: Use arror cursor in blame viewer file data Since we don't allow the user to select text from the file viewer right now I'm disabling the normal text cursor and putting in a plain arror instead. This way users don't think they can select and copy text, because they can't. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:45 UTC
c9e6bfd Shawn O. Pearce 01 June 2007, 05:04:46 UTC git-gui: Simplify consecutive lines that come from the same commit If two consecutive lines in the final file came from the same commit then we store a "|" in the first column rather than the commit id, for the second and subsequent lines in that block. This cleans up the interface so runs associated with the same commit can be more easily seen visually. We also now use the abbreviation "work" for the uncommitted stuff in your working directory, rather than "0000". This looks nicer to the eyes and explains pretty quickly what is going on. There was also a minor bug in the commit abbreviation column for the last line of the file. This is now also fixed. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:44 UTC
f96cd7b Shawn O. Pearce 01 June 2007, 04:38:31 UTC git-gui: Improve the coloring in blame viewer The git-gui blame viewer has always been ugly as s**t. Linus Torvalds suggested the coloring scheme I'm using here, which is two different shades of grey for the background colors, and black text on a pale green background for the currently selected/focused commit. The difference is a massive improvement. The interface no longer will cause seizures in people who are prone to that sort of thing. It no longer uses a very offensive hot pink. The green being current actually makes sense. And not having the background of the other non-current lines change when you change the current commit is really a big deal. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:43 UTC
bea39c2 Shawn O. Pearce 01 June 2007, 04:08:58 UTC git-gui: Remove empty blank line at end of blame The blame viewer has this silly blank line at the bottom of it; we really don't want to see it displayed as we will never get any blame data for that line (it doesn't exist in the source). Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:43 UTC
d89a494 Shawn O. Pearce 01 June 2007, 04:05:49 UTC git-gui: Cleanup blame::new widget initialization A lot of this code was pre-class, which meant that I just sort of copied and pasted my way through it, rather than being really smart and using a variable for each widget's path name. Since we have a field for each path, we can use those throughout the constructor and make things a lot neater. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:43 UTC
a46fe1c Shawn O. Pearce 01 June 2007, 03:58:55 UTC git-gui: Add a 4 digit commit abbreviation to the blame viewer We now show the first 4 digits of each commit in the left most column of our blame viewer, before the line numbers. These are drawn as the data becomes available from git-blame --incremental, and helps the user to visually group lines together. I'm using only the first 4 digits because within a given cluster of lines its unlikely that two neighboring commits will have the same 4 digit prefix. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:26:42 UTC
9adccb0 Matthijs Melchior 05 June 2007, 21:50:02 UTC New selection indication and softer colors The default font was already bold, so marking the selected file with bold font did not work. Change that to lightgray background. Also, the header colors are now softer, giving better readability. Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 06 June 2007, 05:14:12 UTC
cb8773d Shawn O. Pearce 03 June 2007, 00:09:00 UTC Revert "Make the installation target of git-gui a little less chatty" 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 <spearce@spearce.org> 03 June 2007, 01:01:29 UTC
cfb07cc Shawn O. Pearce 02 June 2007, 20:11:26 UTC git-gui: Verify Tcl/Tk is new enough for our needs For quite a while we have been assuming the user is running on a Tcl/Tk 8.4 or later platform. This may not be the case on some very old systems. Unfortunately I am pretty far down the path of using the Tcl/Tk 8.4 commands and options and cannot easily work around them to support earlier versions of Tcl/Tk. So we'll check that we are using the correct version up front, and if not we'll stop with a related error message. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 03 June 2007, 00:00:55 UTC
6309172 Shawn O. Pearce 02 June 2007, 21:18:46 UTC git-gui: Attach font_ui to all spinbox widgets Earlier I missed making sure our spinbox widgets used the same font as the other widgets around them. This meant that using a main font with a size of 20 would make every widget in the options dialog huge, but the spinboxes would be left with whatever the OS native font is. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 02 June 2007, 23:56:27 UTC
160e822 Shawn O. Pearce 01 June 2007, 22:20:30 UTC git-gui: Don't quit when we destroy a child widget Its wrong to exit the application if we destroy a random widget contained withing something else; especially if its some small trivial thing that has no impact on the overall operation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 02 June 2007, 03:12:56 UTC
c289f6f Alex Riesen 01 June 2007, 23:09:56 UTC Make the installation target of git-gui a little less chatty Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 02 June 2007, 03:08:29 UTC
b8848f7 Shawn O. Pearce 01 June 2007, 03:32:54 UTC git-gui: Allow as few as 0 lines of diff context Johannes Sixt pointed out that dropping to 0 lines of context does allow the user to get more fine-grained hunk selection, especially since we don't currently support "highlight and apply (or revert)". Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 01 June 2007, 03:32:54 UTC
905d9c9 Shawn O. Pearce 30 May 2007, 15:27:49 UTC git-gui: Allow creating a branch when none exists If the user has no branches at all (their refs/heads/ is empty) and they are on a detached HEAD we have a valid repository but there are no branches to populate into the branch pulldown in the create branch dialog. Instead of erroring out we can skip that part of the dialog, much like we do with tracking branches or tags when the user doesn't have any. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 30 May 2007, 23:34:40 UTC
ea75ee3 Shawn O. Pearce 27 May 2007, 04:03:37 UTC git-gui: Guess our share/git-gui/lib path at runtime if possible 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 <spearce@spearce.org> 27 May 2007, 04:03:37 UTC
3d5793b Shawn O. Pearce 24 May 2007, 06:33:13 UTC Correct key bindings to Control-<foo> Alberto Bertogli reported on #git that git-gui was exiting with alt-q, while gitk on the same system was exiting with ctrl-q. That was not what I wanted. I really wanted M1B to be bound to the Control key on most non-Mac OS X platforms, but according to Sam Vilain M1 on most systems means alt. Since gitk always does control, I'm doing the same thing for all non-Mac OS X systems. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 24 May 2007, 06:33:13 UTC
306fc12 Shawn O. Pearce 22 May 2007, 07:22:51 UTC git-gui: Tighten internal pattern match for lib/ directory Our GITGUI_LIBDIR macro was testing only for @@ at the start of the path, assuming nobody would ever find that to be a reasonable prefix for a directory to install our library into. That is most likely a valid assumption, but its even more unlikely they would have the start be @@GITGUI_ and the end be @@. Note that we cannot use the full string here because that would get expanded by the sed replacement in our Makefile. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> 22 May 2007, 07:22:51 UTC
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
back to top