kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Shawn O. Pearce	79c50bf3ee	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>	18 years ago
Shawn O. Pearce	669fbc3d09	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>	18 years ago
Shawn O. Pearce	22c6769d91	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>	18 years ago
Shawn O. Pearce	982cf98fa4	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>	18 years ago
Shawn O. Pearce	d0b741dc08	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>	18 years ago
Shawn O. Pearce	223475a77c	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>	18 years ago
Shawn O. Pearce	ddc1fa8f88	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>	18 years ago
Shawn O. Pearce	b5a4122474	git-gui: Cleanup minor style nit Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	18 years ago
Shawn O. Pearce	8154e1a624	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>	18 years ago
Shawn O. Pearce	74fe898578	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>	18 years ago
Shawn O. Pearce	41bf23d6cc	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>	18 years ago
Shawn O. Pearce	37ebc93f6d	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>	18 years ago
Shawn O. Pearce	c9e6bfd8a9	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>	18 years ago
Shawn O. Pearce	f96cd7b6c9	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>	18 years ago
Shawn O. Pearce	bea39c2ddb	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>	18 years ago
Shawn O. Pearce	d89a494fca	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>	18 years ago
Shawn O. Pearce	a46fe1c1c0	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>	18 years ago
Shawn O. Pearce	b8848f7753	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>	18 years ago
Shawn O. Pearce	905d9c9653	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>	18 years ago
Shawn O. Pearce	76486bbefb	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>	18 years ago
Shawn O. Pearce	0511798f06	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>	18 years ago
Shawn O. Pearce	a0db0d61fb	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>	18 years ago
Shawn O. Pearce	685caf9af6	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>	18 years ago
Shawn O. Pearce	28bf928cf8	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>	18 years ago
Shawn O. Pearce	c74b6c66f0	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>	18 years ago
Shawn O. Pearce	1f07c4e5ce	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>	18 years ago
Shawn O. Pearce	cc1f83fbdf	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>	18 years ago
Shawn O. Pearce	ebcaadabcb	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>	18 years ago
Shawn O. Pearce	1fc4ba86f8	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>	18 years ago
Shawn O. Pearce	349f92e3a2	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>	18 years ago
Shawn O. Pearce	a6c9b081b6	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>	18 years ago
Shawn O. Pearce	60aa065f69	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>	18 years ago
Shawn O. Pearce	a35d65d9c8	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>	18 years ago
Shawn O. Pearce	f522c9b5ed	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>	18 years ago

34 Commits (79c50bf3ee1e0fb5c257ed6f6680cae726a4c412)