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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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/429810Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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
b6047c5a.

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

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: NShawn O. Pearce <spearce@spearce.org>

The default font was already bold, so marking the selected file with bold
font did not work.  Change that to lightgray background.
Also, the header colors are now softer, giving better readability.
Signed-off-by: NMatthijs Melchior <mmelchior@xs4all.nl>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

For quite a while we have been assuming the user is running on
a Tcl/Tk 8.4 or later platform.  This may not be the case on
some very old systems.  Unfortunately I am pretty far down the
path of using the Tcl/Tk 8.4 commands and options and cannot
easily work around them to support earlier versions of Tcl/Tk.
So we'll check that we are using the correct version up front,
and if not we'll stop with a related error message.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Earlier I missed making sure our spinbox widgets used the same font
as the other widgets around them.  This meant that using a main font
with a size of 20 would make every widget in the options dialog huge,
but the spinboxes would be left with whatever the OS native font is.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Its wrong to exit the application if we destroy a random widget
contained withing something else; especially if its some small
trivial thing that has no impact on the overall operation.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

To improve performance on fork+exec impoverished systems (such as
Windows) we want to avoid running git-symbolic-ref on every rescan
if we can do so.  A quick way to implement such an avoidance is to
just read the HEAD ref ourselves; we'll either see it as a symref
(starts with "ref: ") or we'll see it as a detached head (40 hex
digits).  In either case we can treat that as our current branch.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Johannes Sixt pointed out that dropping to 0 lines of context
does allow the user to get more fine-grained hunk selection,
especially since we don't currently support "highlight and
apply (or revert)".
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Recently git-merge learned to avoid generating the diffstat after
a merge by reading the merge.diffstat configuration option.  By
default this option is assumed to be true, as that is the old
behavior.  However we can force it to false by setting it as a
standard boolean option.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Git has supported remote branch deletion for quite some time, but
I've just never gotten around to supporting it in git-gui.  Some
workflows have users push short-term branches to some remote Git
repository, then delete them a few days/weeks later when that topic
has been fully merged into the main trunk.  Typically in that style
of workflow the user will want to remove the branches they created.

We now offer a "Delete..." option in the Push menu, right below the
generic "Push..." option.  When the user opens our generic delete
dialog they can select a preconfigured remote, or enter a random
URL.  We run `git ls-remote $url` to obtain the list of branches and
tags known there, and offer this list in a listbox for the user to
select one or more from.

Like our local branch delete dialog we offer the user a way to filter
their selected branch list down to only those branches that have been
merged into another branch.  This is a very common operation as the
user will likely want to select a range of topic branches, but only
delete them if they have been merged into some sort of common trunk.

Unfortunately our remote merge base detection is not nearly as strict
as the local branch version.  We only offer remote heads as the test
commit (not any local ones) and we require that all necessary commits
to successfully run git-merge-base are available locally.  If one or
more is missing we suggest that the user run a fetch first.

Since the Git remote protocol doesn't let us specify what the tested
commit was when we evaluated our decision to execute the remote delete
there is a race condition here.  The user could do a merge test against
the trunk, determine a topic branch was fully merged, but before they
can start pushing the delete request another user could fast-forward
the remote topic branch to a new commit that is not merged into the
trunk.  The delete will arrive after, and remove the topic, even though
it was not fully merged.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Git's native command line interface has had branch renaming
support for quite a while, through the -m/-M options to the
git-branch command line tool.  This is an extremely useful
feature as users may decide that the name of their current
branch is not an adequate description, or was just entered
incorrectly when it was created.

Even though most people would consider git-branch to be a
Porcelain tool I'm using it here in git-gui as it is the
only code that implements the rather complex set of logic
needed to successfully rename a branch in Git.  Currently
that is along the lines of:

 *) Backup the ref
 *) Backup the reflog
 *) Delete the old ref
 *) Create the new ref
 *) Move the backed up reflog to the new ref
 *) Record the rename event in the reflog
 *) If the current branch was renamed, update HEAD
 *) If HEAD changed, record the rename event in the HEAD reflog
 *) Rename the [branch "$name"] section in the config file

Since that is some rather ugly set of functionality to implement
and get right, and some of it isn't easily accessible through the
raw plumbing layer I'm just cheating by relying on the Porcelain.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The Windows and Mac OS X platforms do not generally use the tearoff
menu feature found on traditional X11 based systems.  On Windows the
Tk engine does support the feature, but it really is out of place and
just confuses people who aren't used to working on a UNIX system.  On
Mac OS X its not supported for the root menu bar and its submenus, as
it doesn't fit into the overall platform UI model.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If we cannot locate our git-gui library directory, or we find it
but the tclIndex file is not present there (or it is present but
is not something we are allowed to read) the user cannot use the
application.  Rather than silently ignoring the errors related to
the tclIndex file being unavailable we report them up front and
display to the user why we cannot start.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

When we are using our "non-optimized" tclIndex format (which is
just a list of filenames, in the order necessary for source'ing)
we are doing all of our loading before we even tested to see if
GITGUI_VERBOSE was set in the environment.  This meant we never
showed the files as we sourced them into the environment.

Now we setup our overloaded auto_load and source scripts before
we attempt to define our library path, or source the scripts that
it mentions.  This way GITGUI_VERBOSE is always honored if set.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Because we now try to automatically guess the library directory
in certain installations users may wonder where git-gui is getting
its supporting files from.  We now display this location in our
About dialog, and we also include the location we are getting our
Git executables from.

Unfortunately users cannot use this 'About git-gui' dialog to
troubleshoot library loading problems; the dialog is defined by
code that exists in the library directory, creating a catch-22.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

In some workflows it is common for a large number of temporary
branches to be created in a remote repository, get fetched to
clients that typically only use git-gui, and then later have
those branches deleted from the remote repository once they have
been fully merged into all destination branches.  Users of git-gui
would obviously like to have their local tracking branches cleaned
up for them, otherwise their local tracking branch namespace would
grow out of control.

The best known way to remove these tracking branches is to run
"git remote prune <remotename>".  Even though it is more of a
Porcelain command than plumbing I'm invoking it through the UI,
because frankly I don't see a reason to reimplement its ls-remote
output filtering and config file parsing.

A new configuration option (gui.pruneduringfetch) can be used to
automatically enable running "git remote prune <remotename>" after
the fetch of that remote also completes successfully.  This is off
by default as it require an additional network connection and is
not very fast on Cygwin if a large number of tracking branches have
been removed (due to the 2 fork+exec calls per branch).
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Johannes Sixt asked me to try to avoid embedding the runtime location
of git-gui's library directory in the executable script.  Not embedding
it helps the MinGW to be relocatable to another directory should a user
wish to install the programs in a directory other than the location the
packager wanted them to be installed into.

Most of this is a hack.  We try to determine if the path of our master
git-gui script will be able to locate the lib by ../share/git-gui/lib.
This should be true if $(gitexecdir) and $(libdir) have the same prefix.
If they do then we defer the assignment of $(libdir) until runtime, and
we get it from $argv0 rather than embedding it into the script itself.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Alberto Bertogli reported on #git that git-gui was exiting with
alt-q, while gitk on the same system was exiting with ctrl-q.
That was not what I wanted.  I really wanted M1B to be bound to
the Control key on most non-Mac OS X platforms, but according to
Sam Vilain M1 on most systems means alt.  Since gitk always does
control, I'm doing the same thing for all non-Mac OS X systems.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Our GITGUI_LIBDIR macro was testing only for @@ at the start of
the path, assuming nobody would ever find that to be a reasonable
prefix for a directory to install our library into.  That is most
likely a valid assumption, but its even more unlikely they would
have the start be @@GITGUI_ and the end be @@.  Note that we
cannot use the full string here because that would get expanded
by the sed replacement in our Makefile.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Petr Baudis pointed out the main git.git repository's Makefile dies
now if git-gui 0.7.0-rc1 or later is being used and TCL_PATH was not
set to a working tclsh program path.  This breaks people who may have
a working build configuration today and suddenly upgrade to the latest
git release.

The tclIndex is required for git-gui to load its associated lib files,
but using the Tcl auto_load procedure to source only the files we need
is a performance optimization.  We can emulate the auto_load by just
source'ing every file in that directory, assuming we source class.tcl
first to initialize our crude class system.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

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