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>

If the user doesn't give us a revision parameter to our blame
subcommand then we can generate blame against the working tree
file by passing the file path off to blame with the --contents
argument.  In this case we cannot obtain the contents of the
file from the ODB; instead we must obtain the contents by
reading the working directory file as-is.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The browser subcommand now optionally accepts a single revision
argument; if no revision argument is supplied then we use the
current branch as the tree to browse.  This is very common, so
its a nice option.

Our blame subcommand now tries to perform the same assumptions
as the command line git-blame; both the revision and the file
are optional.  We assume the argument is a filename if the file
exists in the working directory, otherwise we assume the argument
is a revision name.  A -- can be supplied between the two to force
parsing, or before the filename to force it to be a filename.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

I think it was Andy Parkins who pointed out that git gui blame HEAD f
does not work if f is in a subdirectory and we are currently running
git-gui within that subdirectory.  This is happening because we did
not take the user's prefix into account when we computed the file
path in the repository.

We now assume the prefix as returned by rev-parse --show-prefix is
valid and we use that during the command line blame subcommand when
we apply the parameters.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Our blame viewer code has historically been a mess simply
because the data for multiple viewers was all crammed into
a single pair of Tcl arrays.  This made the code hard to
read and even harder to maintain.

Now that we have a slightly better way of tracking the data
for our "meta-widgets" we can make use of it here in the
blame viewer to cleanup the code and make it easier to work
with long term.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Now that we have a slightly easier method of working with per-widget
data we should make use of that technique in our browser and console
meta-widgets, as both have a decent amount of information that they
store on a per-widget basis and our current approach of handling
it is difficult to follow.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

All menu entries talk about "staging" and "unstaging" changes, but the
titles of the file lists use different wording, which may confuse
newcomers.
Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Like the console procs I have moved the code related to merge
support into their own namespace, so that they are isolated
from the rest of the world.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Users who are used to vi and recent versions of gitk may want
to scroll the diff region using vi style keybindings.  Since
these aren't bound to anything else and that widget does not
accept focus for data input, we can easily support that too.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

I'm finding it difficult to work with a 6,000+ line Tcl script
and not go insane while looking for a particular block of code.
Since most of the program is organized into different units of
functionality and not all users will need all units immediately
on startup we can improve things by splitting procs out into
multiple files and let auto_load handle things for us.

This should help not only to better organize the source, but
it may also improve startup times for some users as the Tcl
parser does not need to read as much script before it can show
the UI.  In many cases the user can avoid reading at least half
of git-gui now.

Unfortunately we now need a library directory in our runtime
location.  This is currently assumed to be $(sharedir)/git-gui/lib
and its expected that the Makefile invoker will setup some sort of
reasonable sharedir value for us, or let us assume its going to be
$(gitexecdir)/../share.

We now also require a tclsh (in TCL_PATH) to just run the Makefile,
as we use tclsh to generate the tclIndex for our lib directory.  I'm
hoping this is not an unncessary burden on end-users who are building
from source.

I haven't really made any functionality changes here, this is just a
huge migration of code from one file to many smaller files.  All of
the new changes are to setup the library path and install the library
files.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Whenever we want to execute a git subcommand from the plumbing
layer (and on rare occasion, the more porcelain-ish layer) we
tend to use our proc wrapper, just to make the code slightly
cleaner at the call sites.  I wasn't doing that in a couple of
places, so this is a simple cleanup to correct that.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Rather than passing "-font font_ui" to every widget that we
create we can instead reconfigure the option database for
all widget classes to use our font_ui as the default widget
font.  This way Tk will automatically setup their defaults
for us, and we can reduce the size of the application.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

An earlier change tossed these optionMenu font configurations
all over the code, when really we can just rename the proc to
a hidden internal name and provide our own wrapper to install
the font configuration we really want.

We also don't need to set these option database entries in all
of the procedures that open dialogs; instead we should just set
one time, them after we have the font configuration ready for use.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Since Tk automatically wraps lines for us in tk_messageBox
widgets we don't need to try to wrap them ourselves.  Its
actually worse that we linewrapped this here in the script,
as not all fonts will render this dialog nicely.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

A coworker who was new to git-gui recently tried to make an octopus
merge when he did not quite mean to.  Unfortunately in his case the
branches had file level conflicts and failed to merge with the octopus
strategy, and he didn't quite know why this happened.  Since most users
really don't want to perform an octopus merge this additional safety
valve in front of the merge process is a good thing.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Now that the command line git-commit has made displaying
the subject (first line) of the newly created commit popular
we can easily do the same thing here in git-gui, without the
ugly part of forking off a child process to obtain that first
line.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If the path of our wish executable that are running under
contains spaces we need to make sure they are escaped in
a proper Tcl list, otherwise we are unable to start gitk.

Reported by Randal L. Schwartz on #git.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Uwe Kleine-König discovered git-gui mangled his surname and did
not send the proper UTF-8 byte sequence to git-commit-tree when
his name appeared in the commit message (e.g. Signed-Off-By line).

Turns out this was related to other trouble that I had in the past
with trying to use "fconfigure $fd -encoding $enc" to select the
stream encoding and let Tcl's IO engine do all of the encoding work
for us.  Other parts of git-gui were just always setting the file
channels to "-encoding binary" and then performing the encoding
work themselves using "encoding convertfrom" and "convertto", as
that was the only way I could make UTF-8 filenames work properly.

I found this same bug in the amend code path, and in the blame
display.  So its fixed in all three locations (commit creation,
reloading message for amend, viewing  message in blame).
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

By showing the basename of the directory very early in the
title bar I can more easily locate a particular git-gui
session when I have 8 open at once and my  Windows taskbar
is overflowing with items.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If we generate a blame status string before we have obtained
any annotation data at all from the input file, or if the input
file is empty, our total_lines will be 0.  This causes a division
by 0 error when we blindly divide by the 0 to compute the total
percentage of lines loaded.  Instead we should report 0% done.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If a dialog/window has a default button registered not every
platform associates the return key with that button, but all
users do.  We have to register the binding of the return key
ourselves to make sure the user's expectations of pressing
return will activate the default button are met.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Many git-gui messages were broken into a multiple lines to make
good paragraph width. Unfortunately in reality it breaks the paragraph
width completely, because the dialog window width does not coincide
with the paragraph width created by the current font.

Tcl/Tk's standard dialog boxes are breaking the long lines
automatically, so it is better to make long lines and let the
interpreter do the job.
Signed-off-by: NEygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Made the default buttons on the dialog active and focused upon the
dialog appearence.

Bound 'Escape' and 'Return' keys to the dialog dismissal where it
was appropriate: mainly for dialogs with only one button and no
editable fields, but on console output dialogs as well.
Signed-off-by: NEygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Some parts of git-gui were not respecting the default GUI font.
Most of them were catched and fixed.
Signed-off-by: NEygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

I got a little surprise one day when I tried to run 'git gui version'
outside of a Git repository to determine what version of git-gui was
installed on that system.  Turns out we were doing the repository
check long before we got around to command line argument handling.

We now look to see if the only argument we have been given is
'version' or '--version', and if so, print out the version and
exit immediately; long before we consider looking at the Git
version or working directory.  This way users can still get to
the git-gui version number even if Git's version cannot be read.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

This reverts commit 871f4c97.

Too many users have complained about the credits generator in
git-gui, so I'm backing the entire thing out.  This revert will
finish that series.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Johannes Sixt noticed that git-gui would not let the user commit
a merge created by `git merge -s ours` as the ours strategy does
not alter the tree (that is HEAD^1^{tree} = HEAD^{tree} after the
merge).  The same issue arises from amending such a merge commit.

We now permit an empty commit (no changed files) if we are doing
a merge commit.  Core Git does this with its command line based
git-commit tool, so it makes sense for the GUI to do the same.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Git 1.5.0 and later no longer output useless messages to standard
error when making the initial (or what looks to be) commit of a
repository.  Since /dev/null does not exist on Windows in the
MinGW environment we can't redirect there anyway.  Since Git
does not output anymore, I'm removing the redirection.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Mark Levedahl noticed that git-gui will let you create an empty
normal (non-merge) commit if the file state in the index is out
of whack.  The case Mark was looking at was with the new autoCRLF
feature in git enabled and is actually somewhat difficult to create.

I found a different way to create an empty commit:  turn on the
Trust File Modifications flag, touch a file, rescan, then move
the file into the "Changes To Be Committed" list without looking
at the file's diff.  This makes git-gui think there are files
staged for commit, yet the update-index call did nothing other
than refresh the stat information for the affected file.  In
this case git-gui allowed the user to make a commit that did
not actually change anything in the repository.

Creating empty commits is usually a pointless operation; rarely
does it record useful information.  More often than not an empty
commit is actually an indication that the user did not properly
update their index prior to commit.  We should help the user out
by detecting this possible mistake and guiding them through it,
rather than blindly recording it.

After we get the new tree name back from write-tree we compare
it to the parent commit's tree; if they are the same string and
this is a normal (non-merge, non-amend) commit then something
fishy is going on.  The user is making an empty commit, but they
most likely don't want to do that.  We now pop an informational
dialog and start a rescan, aborting the commit.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>