aboutsummaryrefslogtreecommitdiff
path: root/lib
Commit message (Collapse)AuthorAge
* git-gui: Show a progress meter for checking out filesShawn O. Pearce2007-07-08
| | | | | | | | | | | | | | | Sometimes switching between branches can take more than a second or two, in which case `git checkout` would normally have shown a small progress meter to the user on the terminal to let them know that we are in fact working, and give them a reasonable idea of when we may finish. We now do obtain that progress meter from read-tree -v and include it in our main window's status bar. This allows users to see how many files we have checked out, how many remain, and what percentage of the operation is completed. It should help to keep users from getting bored during a large checkout operation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Change the main window progress bar to use status_barShawn O. Pearce2007-07-08
| | | | | | | | Now that we have a fancy status bar mega-widget we can reuse that within our main window. This opens the door for implementating future improvements like a progress bar. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Extract blame viewer status bar into mega-widgetShawn O. Pearce2007-07-08
| | | | | | | | | | | | | | Our blame viewer has had a very fancy progress bar at the bottom of the window that shows the current status of the blame engine, which includes the number of lines completed as both a text and a graphical meter. I want to reuse this meter system in other places, such as during a branch switch where read-tree -v can give us a progress meter for any long-running operation. This change extracts the code and refactors it as a widget that we can take advantage of in locations other than in the blame viewer. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Allow double-click in checkout dialog to start checkoutShawn O. Pearce2007-07-08
| | | | | | | | | | | If the user double clicks a branch in the checkout dialog then they probably want to start the checkout process on that branch. I found myself doing this without realizing it, and of course it did nothing as there was no action bound to the listbox's Double-Button-1 event handler. Since I did it without thinking, others will probably also try, and expect the same behavior. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Default selection to first matching refShawn O. Pearce2007-07-08
| | | | | | | | | | If we have specifications listed in our revision picker mega-widget then we should default the selection within that widget to the first ref available. This way the user does not need to use the spacebar to activate the selection of a ref within the box; instead they can navigate up/down with the arrow keys and be done with it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Refactor branch switch to support detached headShawn O. Pearce2007-07-08
| | | | | | | | | | | | | | | | | | | | | | | | This is a major rewrite of the way we perform switching between branches and the subsequent update of the working directory. Like core Git we now use a single code path to perform all changes: our new checkout_op class. We also use it for branch creation/update as it integrates the tracking branch fetch process along with a very basic merge (fast-forward and reset only currently). Because some users have literally hundreds of local branches we use the standard revision picker (with its branch filtering tool) to select the local branch, rather than keeping all of the local branches in the Branch menu. The branch menu listing out all of the available branches is simply not sane for those types of huge repositories. Users can now checkout a detached head by ticking off the option in the checkout dialog. This option is off by default for the obvious reason, but it can be easily enabled for any local branch by simply checking it. We also detach the head if any non local branch was selected, or if a revision expression was entered. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Refactor our ui_status_value update techniqueShawn O. Pearce2007-07-08
| | | | | | | | | | | | | | | | | | | | | | | I'm really starting to dislike global variables. The ui_status_value global varible is just one of those that seems to appear in a lot of code and in many cases we didn't even declare it "global" within the proc that updates it so we haven't always been getting all of the updates we expected to see. This change introduces two new global procs: ui_status $msg; # Sets the status bar to show $msg. ui_ready; # Changes the status bar to show "Ready." The second (special) form is used because we often update the area with this message once we are done processing a block of work and want the user to know we have completed it. I'm not fixing the cases that appear in lib/branch.tcl right now as I'm actually in the middle of a huge refactoring of that code to support making a detached HEAD checkout. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Automatically refresh tracking branches when neededShawn O. Pearce2007-07-08
| | | | | | | | | | | | | | If the user is creating a new local branch and has selected to use a tracking branch as the starting revision they probably want to make sure they are using the absolute latest version available of that branch. We now offer a checkbox "Fetch Tracking Branch" (on by default) that instructs git-gui to run git-fetch on just that one branch before resolving the branch name into a commit SHA-1 and making (or updating) the local branch. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Option to default new branches to match tracking branchesShawn O. Pearce2007-07-08
| | | | | | | | | | | | In some workflows users will want to almost always just create a new local branch that matches a remote branch. In this type of workflow it is handy to have the new branch dialog default to "Match Tracking Branch" and "Starting Revision"-Tracking Branch", with the focus in the branch filter field. This can save users working on this type of workflow at least two mouse clicks every time they create a new local branch or switch to one with a fast-forward. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Sort tags descending by tagger dateShawn O. Pearce2007-07-08
| | | | | | | | | | | When trying to create a branch from a tag most people are looking for a recent tag, not one that is ancient history. Rather than sorting tags by their string we now sort them by taggerdate, as this places the recent tags at the top of the list and the very old ones at the end. Tag date works nicely as an approximation of the actual history order of commits. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Enhance choose_rev to handle hundreds of branchesShawn O. Pearce2007-07-08
| | | | | | | | | | | | | | | | | | | | | | One of my production repositories has hundreds of remote tracking branches. Trying to navigate these through a popup menu is just not possible. The list is far larger than the screen and it does not scroll fast enough to efficiently select a branch name when trying to create a branch or delete a branch. This is major rewrite of the revision chooser mega-widget. We now use a single listbox for all three major types of named refs (heads, tracking branches, tags) and a radio button group to pick which of those namespaces should be shown in the listbox. A filter field is shown to the right allowing the end-user to key in a glob specification to filter the list they are viewing. The filter is always taken as substring, so we assume * both starts and ends the pattern the user wanted but otherwise treat it as a glob pattern. This new picker works out really nicely. What used to take me at least a minute to find and select a branch now takes mere seconds. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Fast-forward existing branch in branch create dialogShawn O. Pearce2007-07-08
| | | | | | | | | | | | | | | | | | | If the user elects to create a local branch that has the same name as an existing branch and we can fast-forward the local branch to the selected revision we might as well do the fast-forward for the user, rather than making them first switch to the branch then merge the selected revision into it. After all, its really just a fast forward. No history is lost. The resulting branch checkout may also be faster if the branch we are switching from is closer to the new revision. Likewise we also now allow the user to reset the local branch if it already exists but would not fast-forward. However before we do the actual reset we tell the user what commits they are going to lose by showing the oneline subject and abbreviated sha1, and we also let them inspect the range of commits in gitk. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Allow users to match remote branch names locallyShawn O. Pearce2007-07-08
| | | | | | | | | | | | | Some workflows have users create a local branch that matches a remote branch they have fetched from another repository. If the user wants to push their changes back to that remote repository then they probably want to use the same branch name locally so that git-gui's push dialog can setup the push refspec automatically. To prevent typos with the local branch name we now offer an option to use the remote tracking branch name as the new local branch name. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Maintain remote and source ref for tracking branchesShawn O. Pearce2007-07-08
| | | | | | | | | | | | | | | | | In the next change I want to let the user create their local branch name to match the remote branch name, so that the existing push dialog can push the branch back up to the remote repository without needing to do any sort of remapping. To do that we need to know exactly what branch name the remote system is using. So all_tracking_branches returns a list of specifications, where each specification is itself a list of: - local ref name (destination we fetch into) - remote name (repository we fetch from) - remote ref name (source ref we fetch from) Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Optimize for newstyle refs/remotes layoutShawn O. Pearce2007-07-08
| | | | | | | | | | | | | | | | | | | | | | Most people using Git 1.5.x and later are using the newer style of remotes layout where all of their tracking branches are in refs/remotes and refs/heads contains only the user's own local branches. In such a situation we can avoid calling is_tracking_branch for each head we are considering because we know that all of the heads must be local branches if no fetch option or Pull: line maps a branch into that namespace. If however any remote maps a remote branch into a local tracking branch that resides in refs/heads we do exactly what we did before, which requires scanning through all fetch lines in case any patterns are matched. I also switched some regexp/regsub calls to string match as this can be a faster operation for prefix matching. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Refactor the delete branch dialog to use class systemShawn O. Pearce2007-07-08
| | | | | | | | A simple refactoring of the delete branch dialog to allow use of the class construct to better organize the code and to reuse the revision selection code of our new choose_rev mega-widget. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Abstract the revision picker into a mega widgetShawn O. Pearce2007-07-08
| | | | | | | | | | This rather large change pulls the "Starting Revision" part of the new branch dialog into a mega widget that we can use anytime we need to select a commit SHA-1. To make use of the mega widget I have also refactored the branch dialog to use the class system, much like the delete remote branch dialog already does. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git-gui: Teach class system to support [$this cmd] syntaxShawn O. Pearce2007-07-08
| | | | | | | | | | | | | | | | | | | | | | | | Its handy to be able to ask an object to do something for you by handing it a subcommand. For example if we want to get the value of an object's private field the object could expose a method that would return that value. Application level code can then invoke "$inst get" to perform the method call. Tk uses this pattern for all of its widgets, so we'd certainly like to use it for our own mega-widgets that we might develop. Up until now we haven't needed such functionality, but I'm working on a new revision picker mega-widget that would benefit from it. To make this work we have to change the definition of $this to actually be a procedure within the namespace. By making $this a procedure any caller that has $this can call subcommands by passing them as the first argument to $this. That subcommand then needs to call the proper subroutine. Placing the dispatch procedure into the object's variable namespace ensures that it will always be deleted when the object is deleted. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Merge branch 'maint'Shawn O. Pearce2007-07-08
|\ | | | | | | | | * maint: git-gui: Skip nicknames when selecting author initials
| * git-gui: Skip nicknames when selecting author initialsShawn O. Pearce2007-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Our blame viewer only grabbed the first initial of the git.git author string "Simon 'corecode' Schubert". Here the problem was we looked at Simon, pulled the S into the author initials, then saw the single quote as the start of the next name and did not like this character as it was not an uppercase letter. We now skip over single quoted nicknames placed within the author name field and grab the initials following it. So the above name will get the initials SS, rather than just S. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | git-gui: use "blame -w -C -C" for "where did it come from, originally?"Junio C Hamano2007-07-08
| | | | | | | | | | | | | | | | | | | | | | The blame window shows "who wrote the piece originally" and "who moved it there" in two columns. In order to identify the former more correctly, it helps to use the new -w option. [sp: Minor change to only enable -w if underlying git >= 1.5.3] Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | git-gui: Honor rerere.enabled configuration optionShawn O. Pearce2007-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recently in git.git change b4372ef136 Johannes Schindelin taught git-commit.sh to invoke (or skip) calling git-rerere based upon the rerere.enabled configuration setting: So, check the config variable "rerere.enabled". If it is set to "false" explicitely, do not activate rerere, even if .git/rr-cache exists. This should help when you want to disable rerere temporarily. If "rerere.enabled" is not set at all, fall back to detection of the directory .git/rr-cache. We now do the same logic in git-gui's own commit implementation. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | Merge branch 'maint'Shawn O. Pearce2007-07-06
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | * maint: git-gui: Ensure windows shortcuts always have .bat extension git-gui: Include a Push action on the left toolbar git-gui: Bind M1-P to push action git-gui: Don't bind F5/M1-R in all windows Conflicts: git-gui.sh
| * git-gui: Ensure windows shortcuts always have .bat extensionShawn O. Pearce2007-07-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently under some setups on Windows Tk is hiding our file extension recommendation of ".bat" from the user and that is allowing the user to create a shortcut file which has no file extension. Double clicking on such a file in Windows Explorer brings up the associate file dialog, as Windows does not know what application to launch. We now append the file extension ".bat" to the filename of the shortcut file if it has no extension or if it has one but it is not ".bat". Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | git-gui: Correct resizing of remote branch delete dialogShawn O. Pearce2007-07-04
| | | | | | | | | | | | | | | | | | | | | | | | The status field of the remote branch delete dialog was marked to expand, which meant that if the user grew the window vertically most of the new vertical height was given to the status field and not to the branch list. Since the status field is just a single line of text there is no reason for it to gain additional height, instead we should make sure all additional height goes to the branch list. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | git-gui: Start blame windows as tall as possibleShawn O. Pearce2007-07-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most users these days are using a windowing system attached to a monitor that has more than 600 pixels worth of vertical space available for application use. As most files stored by Git are longer than they are wide (have more lines than columns) we want to dedicate as much vertical space as we can to the viewer. Instead of always starting the window at ~600 pixels high we now start the window 100 pixels shorter than the screen claims it has available to it. This -100 rule is used because some popular OSen add menu bars at the top of the monitor, and docks on the bottom (e.g. Mac OS X, CDE, KDE). We want to avoid making our window too big and causing the window's resize control from being out of reach of the user. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | Merge branch 'maint'Shawn O. Pearce2007-07-04
|\ \ | |/ | | | | | | * maint: git-gui: Unlock the index when cancelling merge dialog
| * git-gui: Unlock the index when cancelling merge dialogShawn O. Pearce2007-07-04
| | | | | | | | | | | | | | | | | | Pressing the escape key while in the merge dialog cancels the merge and correctly unlocks the index. Unfortunately this is not true of the Cancel button, using it closes the dialog but does not release the index lock, rendering git-gui frozen until you restart it. We now properly release the index lock when the Cancel button is used. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | Merge branch 'maint'Shawn O. Pearce2007-06-27
|\ \ | |/ | | | | | | | | | | * maint: git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack git-gui: Don't nice git blame on MSYS as nice is not supported git-gui: Don't require $DISPLAY just to get --version
| * git-gui: Don't nice git blame on MSYS as nice is not supportedShawn O. Pearce2007-06-27
| | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'maint'Shawn O. Pearce2007-06-20
|\ \ | |/ | | | | | | | | * maint: git-gui: Bind Tab/Shift-Tab to cycle between panes in blame git-gui: Correctly install to /usr/bin on Cygwin
| * git-gui: Bind Tab/Shift-Tab to cycle between panes in blameShawn O. Pearce2007-06-20
| | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'maint'Shawn O. Pearce2007-06-11
|\ \ | |/ | | | | | | * maint: git-gui: Save geometry before the window layout is damaged git-gui: Give amend precedence to HEAD over MERGE_MSG
| * git-gui: Save geometry before the window layout is damagedShawn O. Pearce2007-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'maint'Shawn O. Pearce2007-06-11
|\ \ | |/ | | | | | | * maint: git-gui: Include 'war on whitespace' fixes from git.git
| * git-gui: Include 'war on whitespace' fixes from git.gitShawn O. Pearce2007-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'maint'Shawn O. Pearce2007-06-11
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: (38 commits) git-gui: Changed blame header bar background to match main window git-gui: Favor the original annotations over the recent ones git-gui: Improve our labeling of blame annotation types git-gui: Use three colors for the blame viewer background git-gui: Jump to original line in blame viewer git-gui: Display both commits in our tooltips git-gui: Run blame twice on the same file and display both outputs git-gui: Display the "Loading annotation..." message in italic git-gui: Rename fields in blame viewer to better descriptions git-gui: Label the uncommitted blame history entry git-gui: Switch internal blame structure to Tcl lists git-gui: Cleanup redundant column management in blame viewer git-gui: Better document our blame variables git-gui: Remove unused commit_list from blame viewer git-gui: Automatically expand the line number column as needed git-gui: Make the line number column slightly wider in blame git-gui: Use lighter colors in blame view git-gui: Remove unnecessary space between columns in blame viewer git-gui: Remove the loaded column from the blame viewer git-gui: Clip the commit summaries in the blame history menu ...
| * git-gui: Changed blame header bar background to match main windowgitgui-0.7.3Shawn O. Pearce2007-06-08
| | | | | | | | | | | | | | | | | | | | | | 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>
| * git-gui: Favor the original annotations over the recent onesShawn O. Pearce2007-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * git-gui: Improve our labeling of blame annotation typesShawn O. Pearce2007-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * git-gui: Use three colors for the blame viewer backgroundShawn O. Pearce2007-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * git-gui: Jump to original line in blame viewerShawn O. Pearce2007-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * git-gui: Display both commits in our tooltipsShawn O. Pearce2007-06-06
| | | | | | | | | | | | | | | | | | | | 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>
| * git-gui: Run blame twice on the same file and display both outputsShawn O. Pearce2007-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * git-gui: Display the "Loading annotation..." message in italicShawn O. Pearce2007-06-06
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * git-gui: Rename fields in blame viewer to better descriptionsShawn O. Pearce2007-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * git-gui: Label the uncommitted blame history entryShawn O. Pearce2007-06-06
| | | | | | | | | | | | | | | | | | | | 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>
| * git-gui: Switch internal blame structure to Tcl listsShawn O. Pearce2007-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * git-gui: Cleanup redundant column management in blame viewerShawn O. Pearce2007-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * git-gui: Better document our blame variablesShawn O. Pearce2007-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>