Simon Sasburg noticed that on X11 if there are more fonts than can
fit in the height of the screen Tk's native tk_optionMenu does not
offer scroll arrows to the user and it is not possible to review
all choices or to select those that are off-screen.  On Mac OS X
the tk_optionMenu works properly but is awkward to navigate if the
list is long.

This is a rewrite of our font selection by providing a new modal
dialog that the user can launch from the git-gui Options panel.
The dialog offers the user a scrolling list of fonts in a pane.
An example text shows the user what the font looks like at the size
they have selected.  But I have to admit the example pane is less
than ideal.  For example in the case of our diff font we really
should show the user an example diff complete with our native diff
syntax coloring.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Acked-by: NSimon Sasburg <simon.sasburg@gmail.com>

This is a very trivial hack to define a global mc procedure that
does not actually perform i18n translations on its input strings.
By declaring an mc procedure here in our maint version of git-gui
we can take patches that are intended for the latest development
version of git-gui and easily backport them without needing to
tweak the mc calls first.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The Windows port of Tk does not have the send command so we
cannot delete it from our global namespace, but the Mac OS
X and X11 ports do have it.  Switching this delete attempt
into a catch makes send go away, or stay away.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Oddly enough `git ls-files --others` supplies us the name of an
untracked submodule by including the trailing slash but that
same git version will not accept the name with a trailing slash
through `git update-index --stdin`.  Stripping off that final
slash character before loading it into our file lists allows
git-gui to stage changes to submodules just like any other file.

This change should give git-gui users some basic submodule support,
but it is strictly at the plumbing level as we do not actually know
about calling the git-submodule porcelain that is a recent addition
to git 1.5.3.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If `git ls-files --others` returned us the name of a directory then
it is because Git has decided that this directory itself contains a
valid Git repository and its files shouldn't be listed as untracked
for this repository.

In such a case we should label the object as a Git repository and
not just as a directory.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

git-gui has a minor problem with regards to symlinks that point
to directories.

	git init
	mkdir realdir
	ln -s realdir linkdir
	git gui

Now clicking on file names in the "unstaged changes" window,
there's a problem coming from the "linkdir" symlink: git-gui
complains with

	error reading "file4": illegal operation on a directory

...even though git-gui can add that same symlink to the index just
fine.

This patch fix this by adding a check.

[sp: Minor fix to use {link} instead of "link" in condition
     and to only open the path if it is not a symlink.]
Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Dmitry V. Levin pointed out that on GNU linux libdir is often used
in Makefiles to mean "/usr/lib" or "/usr/lib64", a directory that
is meant to hold platform-specific binary files.  Using a different
libdir meaning here in git-gui's Makefile breaks idomatic expressions
like rpm specifile "make libdir=%_libdir".

Originally I asked that the git.git Makefile undefine libdir before
it calls git-gui's own Makefile but it turns out this is very hard
to do, if not impossible.  Renaming our libdir to gg_libdir resolves
this case with a minimum amount of fuss on our part.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The Tk designers blessed us with the "send" command, which on X11
will allow anyone who can connect to your X server to evaluate any
Tcl code they desire within any running Tk process.  This is just
plain nuts.  If git-gui wants someone running Tcl code within it
then would ask someone to supply that Tcl code to it; waiting for
someone to drop any random Tcl code into us is not fantastic idea.

By renaming send to the empty name the procedure will be removed
from the global namespace and Tk will stop responding to random Tcl
evaluation requests sent through the X server.  Since there is no
facility to filter these requests it is unlikely that we will ever
consider enabling this command.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Steps to reproduce the bug:

 $ mkdir repo && cd repo && git init
 Initialized empty Git repository in .git/
 $ touch 'foo%3Fsuite'
 $ git-gui

Then click on the 'foo%3Fsuite' icon to include it in a changeset, a
popup comes with:
'Error: bad field specifier "F"'

Vincent Danjean noticed the problem and also suggested the fix, reported
through
 http://bugs.debian.org/441167Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Today I found yet another way for the "Stage Hunk" and "Unstage
Hunk" context menu actions to leave the wrong state enabled in
the UI.  The problem this time was that I connected the state
determination to the value of $::current_diff_side (the side the
diff is from).  When the user was last looking at a diff from the
index side and unstages everything the diff panel goes empty, but
the action stayed enabled as we always assumed unstaging was a
valid action.

This change moves the logic for determining when the action is
enabled away from the individual side selection, as they really
are two unrelated concepts.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If the user tried to detach their HEAD while keeping the working
directory on the same commit we actually did not completely do
a detach operation internally.  The problem was caused by git-gui
not forcing the HEAD symbolic ref to be updated to a SHA-1 hash
when we were not switching revisions.  Now we update the HEAD ref
if we aren't currently detached or the hashes don't match.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Current versions of git-remote apparently are passing the -w option
to Perl as part of the shbang line:

  #!/usr/bin/perl -w

this caused a problem in git-gui and gave the user a Tcl error with
the message: "git-remote not supported: #!/usr/bin/perl -w".

The fix for this is to treat the shbang line as a Tcl list and look
at the first element only for guessing the executable name.  Once
we know the executable name we use the remaining elements (if any
exist) as arguments to the executable, before the script filename.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

David Kastrup pointed out that the following sequence was not
working as we had intended:

  $ cd lib
  $ git gui blame console.tcl
  fatal: cannot stat path lib/console.tcl: No such file or directory

The problem here was we disabled the chdir to the root of the
working tree when we are running with a "bare allowed" feature
such as blame or browser, but we still kept the prefix we found via
`git rev-parse --show-prefix`.  This caused us to try and look for
the file "console.tcl" within the subdirectory but also include
the subdirectory's own path from the root of the working tree.
This is unlikely to succeed, unless the user just happened to have
a "lib/lib/console.tcl" file in the repository, in which case we
would produce the wrong result.

In the case of a bare repository we shouldn't get back a value from
`rev-parse --show-prefix`, so really $_prefix should only be set
to the non-empty string if we are in a working tree and we are in a
subdirectory of that working tree.  If this is true we really want
to always be at the top level of the working tree, as all paths are
accessed as though they were relative to the top of the working tree.
Converting $_prefix to a ../ sequence is a fairly simple approach
to moving up the requisite levels.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

git-apply does not accept a patch that was generated as a three-way
combined diff format such as we see during merge conflicts.  If we
get such a diff in our diff viewer and try to send it to git-apply
it just errors out and the user is left confused wondering why they
cannot stage that hunk.

Instead of feeding a known to be unacceptable hunk to git-apply we
now just disable the stage/unstage context menu option if the hunk
came from a three way diff.  The user may still be confused about
why they cannot work with a combined diff, but at least they are
only confused as to why git-gui is not offering them the action.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The current popup_diff_menu procedure is somewhat messy as it has a
few duplications of the same logic in each of the different legs of
the routine.  We can simplify these by setting a few state variables
in the different legs.

No functional change, just a cleanup to make it easier to implement
future functional changes within this block.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If the tclsh command was not available to us at the time we were
"built" our lib/tclIndex just lists all of our library files and
we source all of them at once during startup, rather than trying
to lazily load only the procedures we need.  This is a problem as
some of our library code now depends upon the git-version proc,
and that proc is not defined until after the library was fully
loaded.

I'm moving the library loading until after we have determined the
version of git we are talking to, as this ensures that the required
git-reversion procedure is defined before any library code can be
loaded.  Since error_popup is defined in the library we instead use
tk_messageBox directly for errors found during the version detection.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

In a13ee29b I totally broke the
"Stage Hunk For Commit" feature by making this menu item always
appear in a disabled state, so it was never invokable.  A "teaser
feature", just sitting there taunting the poor user who has become
used to having it available.

The issue caused by a13ee was I added a test to look at the data
in $file_states, but I didn't do that test correctly as it was
always looking at a procedure local $file_states array, which is
not defined, so the test was always true and we always disabled
the menu entry.

Instead we only want to disable the menu entry if the current file
we are looking at has no file state information (git-gui is just a
very confused little process) or it is an untracked file (and we
cannot stage individual hunks).
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Earlier when I rewrote the merge implementation for git-gui I broke
it such that the conflict markers for the "theirs" side of the hunk
was using a full SHA-1 ID in hex, rather than the name of the branch
the user had merged.  This was because I got paranoid and passed off
the full SHA-1 to git-merge, instead of giving it the reference name
the user saw in the merge dialog.

I'd still like to resolve the SHA-1 upfront in git-gui and always use
that value throughout the merge, but I can't do that until we have a
full implementation of git-merge written in Tcl.  Until then its more
important that the conflict markers be useful to the end-user, so we
need to pass off the ref name and not the SHA-1 ID.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

cehteh on #git noticed that secondary windows such as console
windows from push/fetch/merge or the blame browser failed on ion
when we tried to open them a second time.

The issue turned out to be the fact that on ion [winfo ismapped .]
returns false if . is not visible right now because it has been
obscured by another window in the same panel.  So we need to keep
track of whether or not the root window has been displayed for this
application, and once it has been we cannot ever assume that ismapped
is going to return true.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

OS X sends Button-2 on a "real" right click, such as with a three
button mouse, or by using the two-finger trackpad click.
Signed-off-by: NVäinö Järvelä <v@pp.inet.fi>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If there is no path currently shown in the diff viewer then we
were getting Tcl errors anytime the user right-clicked on the
diff viewer to bring up its popup menu.  The bug here is caused
by trying to get the file_state for the empty string; this path
is never seen so we never have file_state for it.  In such cases
we now disable the Stage Hunk For Commit option.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

This is just a small code movement to cleanup how we generate
the command line for a merge.  I'm only doing it to make the
next series of changes slightly more readable.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

This is a replacement of all of the icons in our tree browser
window, as the prior icons just looked too 1980s Tk-ish.  The
icons used here are actually from a KDE themed look, so they
might actually be familiar to some users of git-gui.

Aside from using more modern looking icons we now have a special
icon for executable blobs, to make them stand out from the normal
non-executable blobs.  We also denote symlinks now with a different
icon, so they stand out from the other types of objects in the tree.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If the user looks at an untracked file in our diff pane we used
to offer "Stage Hunk For Commit" in the context menu when they
right-clicked in that pane.  The problem is we don't actually
have any diff hunks in untracked files, so there is nothing to
really select for staging.  So we now grey out the menu item,
so the user cannot invoke it and think its broken when it does
not perform any useful action.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If we are started for only a blame/browser/citool run we don't
usually initialize the list of remotes, or determine which refs
are tracking branches and which are local branch heads.  This is
because some of that work is relatively expensive and is usually
not going to be needed if we are started only for a blame, or to
make a single commit.

However by not loading the remote configuration we were crashing
if the user tried to open a browser for another branch through
the Repository menu, as our load_all_heads procedure was unable
to decide which refs/heads/ items were actually local heads.  We
now force all remote configuration data to be loaded if we have
not done so already and we are trying to create a revision mega
widget.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Resetting a large number of files on a slow filesystem can take
considerable time, just as switching branches in such a case can
take more than two seconds.  We now take advantage of the progress
meter output by read-tree and show it in the main window status
bar, just like we do during checkout (branch switch).
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Recent git versions have a git-status that honors the core.excludesfile
configuration option when it reports on untracked files.  Unfortunately
I missed the introduction of this configuration option in the core
porcelain implementation, so it was not reflected here in git-gui.

Found and reported by Lars Noschinski <lars@public.noschinski.de>.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Also, the warning message when clicking "Reset" is adapted to
the wording "Reset" rather than a confusion "Cancel commit?".
Signed-off-by: NChristian Stimming <stimming@tuhh.de>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

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

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

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

Misc. code cleanups in the merge dialog's binding setup and action
button creation.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

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

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

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

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

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

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

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