git-gui: Use sh.exe in Cygwin shortcuts

Because we are trying to execute /bin/sh we know it must be a real
Windows executable and thus ends with the standard .exe suffix.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Paper bag fix for Cygwin shortcut creation

We cannot execute the git directory, it is not a valid Tcl command
name.  Instead we just want to pass it as an argument to our sq
proc.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'maint'

* maint:
  git-gui: Don't linewrap within console windows
  git-gui: Correct ls-tree buffering problem in browser

git-gui: Don't linewrap within console windows

If we get more than 80 characters of text in a single line odds
are it is output from git-fetch or git-push and its showing a
lot of detail off to the right edge that is not so important to
the average user.  We still want to make sure we show everything
we need, but we can get away with that information being off to
the side with a horizontal scrollbar.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Correct ls-tree buffering problem in browser

Our file browser was showing bad output as it did not properly buffer
a partial record when read from `ls-tree -z`.  This did not show up on
my Mac OS X system as most trees are small, the pipe buffers generally
big and `ls-tree -z` was generally fast enough that all data was ready
before Tcl started to read.  However on my Cygwin system one of my
production repositories had a large enough tree and packfile that it
took a couple of pipe buffers for `ls-tree -z` to complete its dump.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Improve the Windows and Mac OS X shortcut creators

We now embed any GIT_* and SSH_* environment variables as well as
the path to the git wrapper executable into the Mac OS X .app file.
This should allow us to restore the environment properly when
we restart.

We also try to use proper Bourne shell single quoting when we can,
as this avoids any sort of problems that might occur due to a path
containing shell metacharacters.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Teach console widget to use git_read

Now that we are pretty strict about setting up own absolute paths to
any git helper (saving a marginal runtime cost to resolve the tool)
we can do the same in our console widget by making sure all console
execs go through git_read if they are a git subcommand, and if not
make sure they at least try to use the Tcl 2>@1 IO redirection if
possible, as it should be faster than |& cat.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Perform our own magic shbang detection on Windows

If we cannot locate a .exe for a git tool that we want to run than
it may just be a Bourne shell script as these are popular in Git.
In such a case the first line of the file will say "#!/bin/sh" so
a UNIX kernel knows what program to start to parse and run that.
But Windows doesn't support shbang lines, and neither does the Tcl
that comes with Cygwin.

We can pass control off to the git wrapper as that is a real Cygwin
program and can therefore start the Bourne shell script, but that is
at least two fork+exec calls to get the program running.  One to do
the fork+exec of the git wrapper and another to start the Bourne shell
script.  If the program is run multiple times it is rather expensive
as the magic shbang detection won't be cached across executions.

On MinGW/MSYS we don't have the luxury of such magic detection.  The
MSYS team has taught some of this magic to the git wrapper, but again
its slower than it needs to be as the git wrapper must still go and
run the Bourne shell after it is called.

We now attempt to guess the shbang line on Windows by reading the
first line of the file and building our own command line path from
it.  Currently we support Bourne shell (sh), Perl and Python.  That
is the entire set of shbang lines that appear in git.git today.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Treat `git version` as `git --version`

We know that the version subcommand of git is special.  It does not
currently have an executable link installed into $gitexecdir and we
therefore would never match it with one of our file exists tests.
So we forward any invocations to it directly to the git wrapper, as
it is a builtin within that executable.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Assume unfound commands are known by git wrapper

If we cannot locate a command in $gitexecdir on our own then it may
just be because we are supposed to run it by `git $name` rather than
by `git-$name`.  Many commands are now builtins, more are likely to
go in that direction, and we may see the hardlinks in $gitexecdir go
away in future versions of git.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Correct gitk installation location

The master Makefile in git.git installs gitk into bindir, not
gitexecdir, which means gitk is located as a sibling of the git
wrapper and not as though it were a git helper tool.

We can also avoid some Tcl concat operations by letting eval do
all of the heavy lifting; we have two proper Tcl lists ($cmd and
$revs) that we are joining together and $revs is currently never
an empty list.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Always use absolute path to all git executables

Rather than making the C library search for git every time we want
to execute it we now search for the main git wrapper at startup, do
symlink resolution, and then always use the absolute path that we
found to execute the binary later on.  This should save us some
cycles, especially on stat challenged systems like Cygwin/Win32.

While I was working on this change I also converted all of our
existing pipes ([open "| git ..."]) to use two new pipe wrapper
functions.  These functions take additional options like --nice
and --stderr which instructs Tcl to take special action, like
running the underlying git program through `nice` (if available)
or redirect stderr to stdout for capture in Tcl.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Show a progress meter for checking out files

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_bar

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-widget

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 checkout

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 ref

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: Unabbreviate commit SHA-1s prior to display

If the end-user feeds us an abbreviated SHA-1 on the command line for
`git gui browser` or `git gui blame` we now unabbreviate the value
through `git rev-parse` so that the title section of the blame or
browser window shows the user the complete SHA-1 as Git determined
it to be.

If the abbreviated value was ambiguous we now complain with the
standard error message(s) as reported by git-rev-parse --verify,
so that the user can understand what might be wrong and correct
their command line.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Refactor branch switch to support detached head

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 technique

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: Better handling of detached HEAD

If the current branch is not a symbolic-ref that points to a
name in the refs/heads/ namespace we now just assume that the
head is a detached head.  In this case we return the special
branch name of HEAD rather than empty string, as HEAD is a
valid revision specification and the empty string is not.

I have also slightly improved the current-branch function by
using string functions to parse the symbolic-ref data.  This
should be slightly faster than using a regsub.  I think the
code is clearer too.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Automatically refresh tracking branches when needed

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 branches

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 date

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 branches

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 dialog

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 locally

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 branches

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 layout

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 system

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 widget

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] syntax

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'

* maint:
  git-gui: Skip nicknames when selecting author initials

git-gui: Skip nicknames when selecting author initials

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?"

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: New Git version check support routine

Some newer features of git-gui want to rely on features that are
new to Git 1.5.3.  Since they were added as part of the 1.5.3
development series we cannot use those features with versions of
Git that are older than 1.5.3, such as from the stable 1.5.2 series.

We introduce [git-version >= 1.5.3] to allow the caller to get a
response of 0 if the current version of git is < 1.5.3 and 1 if
the current version of git is >= 1.5.3.  This makes it easy to
setup conditional code based upon the version of Git available to
us at runtime.

Instead of parsing the version text by hand we now use the Tcl
[package vcompare] subcommand to compare the two version strings.
This works nicely, as Tcl as already done all of the hard work
of doing version comparsions.  But we do have to remove the Git
specific components such as the Git commit SHA-1, commit count and
release candidate suffix (rc) as we want only the final release
version number.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Honor rerere.enabled configuration option

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'

* 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 extension

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: Include a Push action on the left toolbar

Pushing changes to a remote system is a very common action for
many users of git-gui, so much so that in some workflows a user
is supposed to push immediately after they make a local commit
so that their change(s) are immediately available for their
teammates to view and build on top of.

Including the push button right below the commit button on the
left toolbar indicates that users should probably perform this
action after they have performed the commit action.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Bind M1-P to push action

Users often need to be able to push the current branch so that they
can publish their recent changes to anyone they are collaborating
with on the project.  Associating a keyboard action with this will
make it easier for keyboard-oriented users to quickly activate the
push features.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Don't bind F5/M1-R in all windows

We actually only want our F5/M1-R keystroke bound in the main window.
Within a browser/blame/console window pressing these keys should not
execute the rescan action.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Correct resizing of remote branch delete dialog

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 possible

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'

* maint:
  git-gui: Unlock the index when cancelling merge dialog

git-gui: Unlock the index when cancelling merge dialog

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'

* maint:
  git-gui: properly popup error if gitk should be started but is not installed

git-gui: properly popup error if gitk should be started but is not installed

On 'Visualize ...', a gitk process is started.  Since it is run in the
background, catching a possible startup error doesn't work, and the error
output goes to the console git-gui is started from.  The most probable
startup error is that gitk is not installed; so before trying to start,
check for the existence of the gitk program, and popup an error message
unless it's found.

This was noticed and reported by Paul Wise through
 http://bugs.debian.org/429810

Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Merge branch 'maint'

* 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 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>

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>

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>

Merge branch 'maint'

* maint:
  git-gui: Bind Tab/Shift-Tab to cycle between panes in blame
  git-gui: Correctly install to /usr/bin on Cygwin

git-gui: Quiet our installation process

Alex Riesen wanted a quieter installation process for git and its
contained git-gui.  His earlier patch to do this failed to work
properly when V=1, and didn't really give a great indication of
what the installation was doing.

These rules are a little bit on the messy side, as each of our
install actions is composed of at least two variables, but in the
V=1 case the text is identical to what we had before, while in the
non-V=1 case we use some more complex rules to show the interesting
details, and hide the less interesting bits.

We now can also set QUIET= (nothing) to see the rules that are used
when V= (nothing), so we can debug those too if we have to.  This is
actually a side-effect of how we insert the @ into the rules we use
for the "lists of things", like our builtins or our library files.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

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>

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>

Merge branch 'maint'

* 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 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>

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>

Merge branch 'maint'

* maint:
  git-gui: Include 'war on whitespace' fixes from git.git

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>

Merge branch 'maint'

* 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 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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

git-gui: Cleanup minor style nit

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

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>

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>

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>

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>

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>

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>

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>

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>

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>