tokkee.org

git-gui: Unify wording to say "to stage" instead of "to add"

Also, the warning message when clicking "Reset" is adapted to
the wording "Reset" rather than a confusion "Cancel commit?".

Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Don't kill modified commit message buffer with merge templates

If the user is in the middle of a merge and has already started to
modify their commit message we were losing the user's changes when
they pressed 'Rescan' after resolving issues or making changes in
the working directory.

The problem here was our background timer that saves the commit
message buffer.  It marks the commit message buffer as not being
modified when it writes it out to disk, so during the rescan we
assumed the buffer should be replaced with what we read from the
MERGE_MSG file.  So we now only read these files from .git if we
have a valid backup file.  Since we clear it on commit this will
only have an impact while the user is actively editing the current
commit.

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

git-gui: Remove usernames from absolute SSH urls during merging

If we are being asked to merge a tracking branch that comes from a
remote repository accessed by the very common SSH URL format of
"user@host:/path/to/repo" then we really don't need the username
as part of the merge message, it only clutters up the history and
makes things more confusing.  So we instead clip the username part
off if the local filesystem path is absolute, as its probably not
going to be an ambiguous URL even when it is missing the username.

On the other hand we cannot clip the username off if the URL is
not absolute, because in such cases (e.g. "user@host:myrepo") the
directory that the repository path is resolved in is relative to
the user's home directory, and the username becomes important.

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

git-gui: Format tracking branch merges as though they were pulls

If we are merging a tracking branch we know exactly what remote URL
that branch is fetched from, and what its name is on that remote
repository.  In this case we can setup a merge message that looks
just like a standard `git-pull $remote $branch` operation by filling
out FETCH_HEAD before we start git-merge, and then run git-merge just
like git-pull does.

I think the result of this behavior is that merges look a lot nicer
when the came off of local tracking branches, because they no longer
say "commit 'origin/...'" to describe the commit being merged but
instead now mention the specific repository we fetched those commits
from.

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

git-gui: Cleanup bindings within merge dialog

Misc. code cleanups in the merge dialog's binding setup and action
button creation.

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

git-gui: Replace merge dialog with our revision picker widget

Now that we only support merging one branch we can offer the user
a better user interface experience by allowing them to select the
revision they want to merge through our revision picking widget.

This change neatly solves the problem of locating a branch out of
a sea of 200 tracking branches, and of dealing with very long branch
names that all have a common prefix.

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

git-gui: Show ref last update times in revision chooser tooltips

If we can we now show the last modification date of a loose ref as
part of the tooltip information shown in the revision picker.  This
gives the user an indication of when was the last time that the ref
was modified locally, and may especially be of interest when looking
at a tracking branch.

If we cannot find the loose ref file than we try to fallback on the
reflog and scan it for the date of the last record.  We don't start
with the reflog however as scanning it backwards from the end is not
an easy thing to do in Tcl.  So I'm being lazy here and just going
through the entire file, line by line.  Since that is less efficient
than a single stat system call, its our fallback strategy.

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

git-gui: Display commit/tag/remote info in tooltip of revision picker

Our revision chooser mega-widget now sets up tooltips for itself so
that it displays details about a commit (or a tag and the commit
it refers to) when the user mouses over that line in the filtered
ref list.  If the item is from a remote tracking branch then we also
show the remote url and what branch on that remote we fetch from, so
the user has a clear concept of where that revision data originated.

To help the merge dialog I've also added a new constructor that
makes the dialog only offer unmerged revisions (those not in HEAD),
as this allows users to avoid performing merges only to get "Already
up to date" messages back from core Git.

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

git-gui: Save remote urls obtained from config/remotes setup

I'm storing the URLs of any pre-configured remote repositories
that we happen to come across so that we can later use these
URLs to show to the user in parts of the UI that might care.

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

git-gui: Avoid unnecessary symbolic-ref call during checkout

If we are checking out the branch we are already on then there is no
need to call symbolic-ref to update the HEAD pointer to the "new"
branch name, it is already correct.

Currently this situation does not happen very often, but it can be
seen in some workflows where the user always recreates their local
branch from a remote tracking branch and more-or-less ignores what
branch he/she is on right now.  As they say, ignorance is bliss.

This case will however become a tad more common when we overload
checkout_op to actually also perform all of our merges.  In that
case we will likely see that the branch we want to "checkout" is
the current branch, as we are actually just merging into it.

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

git-gui: Refactor current branch menu items to make i18n easier

The i18n team has also identified a rather ugly block of code in
git-gui that is used to make a pair of Repository menu items show
the current branch name.  This code is difficult to convert to use
[mc ...] to lookup the translation, so I'm refactoring it into a
procedure.

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

git-gui: Refactor diff popup into a procedure to ease i18n work

The folks working on the i18n version of git-gui have had some
trouble trying to convert these English strings into [mc] calls
due to the double evaluation.  Moving this block into a standard
procedure eliminates the double evaluation, making their work
easier.

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

git-gui: Paper bag fix quitting crash after commit

My earlier introduction of the GITGUI_BCK file (which saves the user's
commit message buffer while they are typing it) broke the Quit function.
If the user makes a commit we delete the GITGUI_BCK file; if they then
immediately quit the application we fail to rename the GITGUI_BCK file
to GITGUI_MSG.  This is because the file does not exist, but our flag
still says it does.  The root cause is we did not unset the flag during
commit.

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

git-gui: Clarify meaning of add tracked menu option

Junio recently pointed out on the mailing list that our "Add Existing"
feature is a lot like `git add -u`, which is generally described as
"(Re)Add Tracked Files".  This came up during discussion of how to
translate "Add Existing" into Japanese, as the individual working on
the translation was not quite sure what the option meant and therefore
had some trouble selecting the best translation.

I'm changing the menu option to "Add Tracked Files To Commit" and the
button to "Add Tracked".  This should help new users to better understand
the actions behind those GUI widgets.

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

git-gui: Fix unnecessary fast-forward during checkout

If we are trying to checkout a local branch which is matched to a
remote tracking branch, but the local branch is newer than the remote
tracking branch we actually just want to switch to the local branch.
The local branch is "Already up to date".

Unfortunately we tossed away the local branch's commit SHA-1 and kept
the remote tracking branch's SHA-1, which meant that the user lost the
local changes when we updated the working directory.  At least we did
not update the local branch ref, so the user's data was still intact.

We now toss the tracking branch's SHA-1 and replace with the local
branch's SHA-1 before the checkout, ensuring that we pass of the right
tree to git-read-tree when we update the working directory.

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

git-gui: Completely remove my Tools/Migrate hack

This menu option of Tools/Migrate has been living inside of git-gui
as a local hack to support some coworkers of mine.  It has no value
to anyone outside of my day-job team and never really should have
been in a release version of git-gui.  So I'm pulling it out, so
that nobody else has to deal with this garbage.

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

git-gui: Internally allow fetch without storing for future pull support

This is actually just an underlying code improvement that has no user
visible component yet.  UI improvements to actually fetch and merge via
an arbitrary remote with no tracking branches must still follow to make
this change useful for the end-user.

Our tracking branch specifications are a Tcl list of three components:

  - local tracking branch name
  - remote name/url
  - remote branch name/tag name

This change just makes the first element optional.  If it is an empty
string we will run the fetch, but have the value be saved only into the
special .git/FETCH_HEAD, where we can pick it up and use it for this one
time operation.

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

git-gui: Skip unnecessary read-tree work during checkout

I totally missed this obvious optimization in the checkout code path.
If our current repository HEAD is actually at the commit we are moving
to, and we agreed to perform this switch earlier, then we have no files
to update in the working directory and any stale mtimes are simply not
of consequence right now.  We can pretend like we ran a read-tree and
skip right into the post-read-tree work, such as updating the branch
and setting the symbolic-ref.

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

git-gui: Simplify error case for unsupported merge types

If we are given a merge type we don't understand in checkout_op there
is probably a bug in git-gui somewhere that allowed this unknown merge
strategy to come into this part of the code path.  We currently only
recognize three merge types ('none', 'ff' and 'reset') but are going
to be supporting more in the future.  Rather than keep editing this
message I'm going with a very generic "Uh, we don't do that!" type of
error.

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

git-gui: Factor out common fast-forward merge case

In both the ff and reset merge_types supported by checkout_op the
result is the same if the merge base of our target commit and the
existing commit is the existing commit: its a fast-forward as the
existing commit is fully contained in the target commit.

This minor cleanup in logic will make it easier to implement a
new kind of merge_type that actually merges the two trees with a
real merge strategy, such as git-merge-recursive.

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

git-gui: Save the merge base during checkout_op processing

I've decided to teach checkout_op how to perform more than just a
fast-forward and reset type of merge.  This way we can also do a full
recursive merge even when we are recreating an existing branch from
a remote.  To help with that process I'm saving the merge-base we
computed during the ff/reset/fail decision process, in case we need
it later on when we actually start a true merge operation.

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

git-gui: Automatically backup the user's commit buffer

A few users have been seeing crashes in Tk when using the undo key
binding to undo the last few keystroke events in the commit buffer.
Unfortunately that means the user loses their commit message and
must start over from scratch when the user restarts the process.

git-gui now saves the user's commit message buffer every couple of
seconds to a temporary file under .git (specifically .git/GITGUI_BCK).
At exit time we rename this file to .git/GITGUI_MSG if there is a
message, the file exists, and it is currently synchronized with the
Tk buffer.  Otherwise we do our usual routine of saving the Tk buffer
to .git/GITGUI_MSG and delete .git/GITGUI_BCK, if it exists.

During startup we favor .git/GITGUI_BCK over .git/GITGUI_MSG.  This
way a crash doesn't take out the user's message buffer but instead
will cause the user to lose only a few keystrokes.  Most people do
not type more than 200 WPM, and with 30 possible saves per minute
we are unlikely to lose more than 7 words.

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

git-gui: Completely remove support for creating octopus merges

I'm working on refactoring the UI of the merge dialog, because as it
currently stands the dialog is absolutely horrible, especially when
you have 200+ branches available from a single remote system.

In that refactoring I plan on using the choose_rev widget to allow
the user to select exactly which branch/commit they want to merge.
However since that only selects a single commit I'm first removing
the code that supports octopus merges.

A brief consultation on #git tonight seemed to indicate that the
octopus merge strategy is not as useful as originally thought when
it was invented, and that most people don't commonly use them.  So
making users fall back to the command line to create an octopus is
actually maybe a good idea here, as they might think twice before
they use it.

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

git-gui: Don't show blame tooltips that we have no data for

If we haven't yet loaded any commit information for a given line but
our tooltip timer fired and tried to draw the tooltip we shouldn't;
there is nothing to show.

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

git-gui: Translate standard encoding names to Tcl ones

This is a essentially a copy of Paul Mackerras encoding support from
gitk.  I stole the code from gitk commit fd8ccbec4f0161, as Paul has
already done all of the hard work setting up this translation table.

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

git-gui: Avoid unnecessary global statements when possible

Running global takes slightly longer than just accessing the variable
via its package name, especially if the variable is just only once in
the procedure, or isn't even used at all in the procedure.  So this is
a minor cleanup for some of our commonly invoked procedures.

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

git-gui: Bind Ctrl/Cmd-M to merge action

Users who merge often may want to access the merge action quickly,
so we now bind M to the merge action.

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

Don't offer my special Tools/Migrate hack unless in multicommit

Users shouldn't see this menu option if they startup a browser or
blame from the command line, especially if they are doing so on a
bare repository.

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

git-gui: Convert merge dialog to use class system

I've found that the class code makes it a whole lot easier to create
more complex GUI code, especially the dialogs.  So before I make any
major improvements to the merge dialog's interface I'm going to first
switch it to use the class system, so the code is slightly cleaner.

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

git-gui: Increase the default height of the revision picker

Showing only five lines of heads/tags is not very useful to a user
when they have about 10 branches that match the filter expression.
The list is just too short to really be able to read easily, at
least not without scrolling up and down.  Expanding the list out
to 10 really makes the revision picker easier to read and access,
as you can read the matching branches much more quickly.

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

git-gui: Clarify the visualize history menu options

Users who are new to Git may not realize that visualizing things in
a repository involves looking at history.  Adding in a small amount
of text to the menu items really helps to understand what the action
might do, before you invoke it.

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

git-gui: Allow users to browse any branch, not just the current one

We now allow users to pick which commit they want to browse through
our revision picking mega-widget.  This opens up in a dialog first,
and then opens a tree browser for that selected commit.  It is a very
simple approach and requires minimal code changes.

I also clarified the language a bit in the Repository menu, to show
that these actions will access files.  Just in case a user is not
quite sure what specific action they are looking for, but they know
they want some sort of file thing.

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

git-gui: Allow browser subcommand to start in subdirectory

Like our blame subcommand the browser subcommand now accepts both
a revision and a path, just a revision or just a path.  This way
the user can start the subcommand on any branch, or on any subtree.

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

git-gui: Allow blame/browser subcommands on bare repositories

A long time ago Linus Torvalds tried to run git-gui on a bare
repository to look at the blame viewer, but it failed to start
because we required that the user run us only from within a
working directory that had a normal git repository associated
with it.

This change relaxes that requirement so that you can start the
tree browser or the blame viewer against a bare repository. In
the latter case we do require that you provide a revision and a
pathname if we cannot find the pathname in the current working
directory.

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

git-gui: Move feature option selection before GIT_DIR init

By moving our feature option determination up before we look for GIT_DIR
we can make a decision about whether or not we need a working tree up
front, before we look for GIT_DIR.  A future change could then allow
us to start in a bare Git repository if we only need access to the ODB.

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

git-gui: Delay the GC hint until after we are running

I'm moving the code related to looking to see if we should GC now
into a procedure closer to where it belongs, the database module.
This reduces our script by a few lines for the single commit case
(aka citool).  But really it just is to help organize the code.

We now perform the check after we have been running for at least
1 second.  This way the main window has time to open up and our
dialog (if we open it) will attach to the main window, instead of
floating out in no-mans-land like it did before on Mac OS X.

I had to use a wait of a full second here as a wait of 1 millisecond
made our console install itself into the main window.  Apparently we
had a race condition with the console code where both the console and
the main window thought they were the main window.

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

git-gui: Let the user continue even if we cannot understand git version

Some users may do odd things, like tag their own private version of
Git with an annotated tag such as 'testver', then compile that git
and try to use it with git-gui.  In such a case `git --version` will
give us 'git version testver', which is not a numeric argument that
we can pass off to our version comparsion routine.

We now check that the cleaned up git version is a going to pass the
version comparsion routine without failure.  If it has a non-numeric
component, or lacks at least a minor revision then we ask the user to
confirm they really want to use this version of git within git-gui.
If they do we shall assume it is git 1.5.0 and run with only the code
that will support.

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

git-gui: Change our initial GC hint to be an estimate

Instead of running a full git-count-objects to count all of the loose
objects we can get a reasonably close approximation by counting the
number of files in the .git/objects/42 subdirectory. This works out
reasonably well because the SHA-1 hash has a fairly even distribution,
so every .git/objects/?? subdirectory should get a relatively equal
number of files.  If we have at least 8 files in .git/objects/42 than it
is very likely there is about 8 files in every other directory, leaving
us with around 2048 loose objects.

This check is much faster, as we need to only perform a readdir of
a single directory, and we can do it directly from Tcl and avoid the
costly fork+exec.

All of the credit on how clever this is goes to Linus Torvalds; he
suggested using this trick in a post commit hook to repack every so
often.

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

git-gui: Don't crash in ask_popup if we haven't mapped main window yet

If we have more than our desired number of objects and we try to
open the "Do you want to repack now?" dialog we cannot include a
-parent . argument if the main window has not been mapped yet.
On Mac OS X it appears this window isn't mapped right away, so we
had better hang avoid including it.

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

git-gui: Delay searching for 'nice' until its really asked for

Not every caller of 'git' or 'git_pipe' wants to use nice to lower the
priority of the process its executing.  In many cases we may never use
the nice process to launch git.  So we can avoid searching our $PATH
to locate a suitable nice if we'll never actually use it.

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

git-gui: Handle git versions of the form n.n.n.GIT

The git-gui version check doesn't handle versions of the form
n.n.n.GIT which you can get by installing from an tarball produced by
git-archive.

Without this change you get an error of the form:
'Error in startup script: expected version number but got "1.5.3.GIT"'

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Always disable the Tcl EOF character when reading

On Windows (which includes Cygwin) Tcl defaults to leaving the EOF
character of input file streams set to the ASCII EOF character, but
if that character were to appear in the data stream then Tcl will
close the channel early.  So we have to disable eofchar on Windows.
Since the default is disabled on all platforms except Windows, we
can just disable it everywhere to prevent any sort of read problem.

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

git-gui: Brown paper bag "dirty git version fix"

My prior change to allow git-gui to run with a version of Git
that was built from a working directory that had uncommitted
changes didn't account for the pattern starting with -, and
that confused Tcl.

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

git-gui: Skip -dirty suffix on core git versions

If the user is running a 'dirty' version of git (one compiled in a
working directory with modified files) we want to just assume it
was a committed version, as we really only look at the part that
came from a real annotated tag anyway.

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

git-gui: Change prior tree SHA-1 verification to use git_read

This cat-file was done on maint, where we did not have git_read
available to us.  But here on master we do, so we should make
use of it.

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

Merge branch 'maint'

* maint:
  git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}

git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}

From Johannes Sixt <J.Sixt@eudaptics.com>:
> It seems that MSYS's wish does some quoting for Bourne shells,
> in particular, escape the first '{' of the "^{tree}" suffix, but
> then it uses cmd.exe to run "git rev-parse". However, cmd.exe does
> not remove the backslash, so that the resulting rev expression
> ends up in git's guts as unrecognizable garbage: rev-parse fails,
> and git-gui hickups in a way that it must be restarted.

Johannes originally submitted a patch to this section of commit.tcl
to use `git rev-parse $PARENT:`, but not all versions of Git will
accept that format.  So I'm just taking the really simple approach
here of scanning the first line of the commit to grab its tree.
About the same cost, but works everywhere.

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

git-gui: Include a space in Cygwin shortcut command lines

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

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>