I'm starting to setup a main window that the user can use to
locate an existing repository, clone an existing repository,
or create a new repository from scratch.  To help do that I
want most of our common UI support already defined before we
start to look for the Git repository, this way if it was not
found we can open a window to help the user locate it.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

* maint:
  git-gui: Ensure .git/info/exclude is honored in Cygwin workdirs
  git-gui: Handle starting on mapped shares under Cygwin
  git-gui: Display message box when we cannot find git in $PATH

Conflicts:

	git-gui.sh

If we are using Cygwin and the git repository is actually a
workdir (by way of git-new-workdir) but this Tcl process is
a native Tcl/Tk and not the Cygwin Tcl/Tk then we are unable
to traverse the .git/info path as it is a Cygwin symlink and
not a standard Windows directory.

So we actually need to start a Cygwin process that can do the
path translation for us and let it test for .git/info/exclude
so we know if we can include that file in our git-ls-files or
not.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

I really cannot explain Cygwin's behavior here but if we start
git-gui through Cygwin on a local drive it appears that Cygwin
is leaving $env(PATH) in Unix style, even if it started a native
(non-Cygwin) Tcl/Tk process to run git-gui.  Yet starting that
same git-gui and Tcl/Tk combination through Cygwin on a network
share causes it to automatically convert $env(PATH) into Windows
style, which broke our internal "which" implementation.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If we cannot find the git executable in the user's $PATH then
we cannot function correctly.  Because we need that to get the
version so we can load our library correctly we cannot rely on
the library function "error_popup" here, as this is all running
before the library path has been configured, so error_popup is
not available to us.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Cygwin has been stuck on the 8.4.1 version of Tcl/Tk for quite some
time, even though the main Tcl/Tk distribution is already shipping
an 8.4.15.  The problem is Tcl/Tk no longer supports Cygwin so
apparently building the package for Cygwin is now a non-trivial task.

Its actually quite easy to build the native Win32 version of Tcl/Tk
by compiling with the -mno-cygwin flag passed to GCC but this means
we lose all of the "fancy" Cygwin path translations that the Tcl
library was doing for us.  This is particularly an issue when we
are trying to start git-gui through the git wrapper as the git
wrapper is passing off a Cygwin path for $0 and Tcl cannot find
the startup script or the library directory.

We now use `cygpath -m -a` to convert the UNIX style paths to Windows
style paths in our startup script if we are building on Cygwin.
Doing so allows either the Cygwin-ized Tcl/Tk 8.4.1 that comes with
Cygwin or a manually built 8.4.15 that is running the pure Win32
implementation to read our script.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The console window titles should also be marked up with i18n strings so
these can be properly localized.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

* maint:
  git-gui: Avoid using bold text in entire gui for some fonts

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

* maint:
  git-gui: Disable native platform text selection in "lists"

Conflicts:

	lib/browser.tcl

Sometimes we use a Tk text widget as though it were a listbox.
This happens typically when we want to show an icon to the left
of the text label or just when a text widget is generally a better
choice then the native listbox widget.

In these cases if we want the user to have control over the selection
we implement our own "in_sel" tag that shows the selected region
and we perform our own selection management in the background
via keybindings and mouse bindings.  In such uses we don't want
the user to be able to activate the native platform selection by
dragging their mouse through the text widget.  Doing so creates a
very confusing display and the user is left wondering what it may
mean to have two different types of selection in the same widget.

Tk doesn't allow us to delete the "sel" tag that it uses internally
to manage the native selection but it will allow us to make it
invisible by setting the tag to have the same display properties
as unselected text.  So long as we don't actually use the "sel"
tag for anything in code its effectively invisible.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The Tcl expression "[append [mc Foo] Bar]" does not return the string
"FooBar" after translation; instead it is setting the variable Foo to
the value Bar, or if Foo is already defined it is appending Bar onto
the end of it.  This is *not* what we wanted to have happen here.

Tcl's join function is actually the correct function but its default
joinStr argument is a single space.  Unfortunately all of our call
sites do not want an extra space added to their string.  So we need
a small wrapper function to make the call to join with an empty
join string.  In C this is (roughly) the job of the strcat function.
Since strcat is not yet used at the global level it is a reasonable
name to use here.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

In 9adccb05 Matthijs Melchior changed our selection colors in the
main index/working directory file lists to use a lightgray as the
background color as this made the UI easier to read on all platforms.

When we did that change we missed doing also doing in the file
browser UI.  Doing so just makes the entire thing UI consistent.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Most of these changes were suggested by Shawn Pearce in an answer
to Johannes Schindelin.

Some strings for the blame module were added too.

[sp: Minor edits in blame module formatting]
Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

* maint:
  git-gui: Paper bag fix "Commit->Revert" format arguments
  git-gui: Provide 'uninstall' Makefile target to undo an installation
  git-gui: Font chooser to handle a large number of font families

The recent bug fix to correctly handle filenames with %s (or any
other valid Tcl format specifier) missed a \ on this line and
caused the remaining format arguments to not be supplied when we
updated the status bar.  This caused a Tcl error anytime the user
was trying to perform a file revert.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Several users have requested a "make uninstall" target be provided
in the stock git-gui Makefile so that they can undo an install
if git-gui goes to the wrong place during the initial install,
or if they are unhappy with the tool and want to remove it from
their system.

We currently assume that the complete set of files we need to delete
are those defined by our Makefile and current source directory.
This could differ from what the user actually has installed if they
installed one version then attempt to use another to perform the
uninstall.  Right now I'm just going to say that is "pilot error".
Users should uninstall git-gui using the same version of source
that they used to make the installation.  Perhaps in the future we
could read tclIndex and base our uninstall decisions on its contents.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

* maint:
  git-gui: Make backporting changes from i18n version easier

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>

Translators working on po files will likely need to know what the
@@noun and @@verb parts are in the original message text, and why
these are different messages in the po files.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Commit is used as both verb and noun. While these happen to be
the same in some languages, they are not the same in all
languages, so disambiguate them using context-sensitive i18n.
Signed-off-by: NHarri Ilari Tapio Liusvaara <hliusvaa@cc.hut.fi>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Ocassionally, one would want to translate the same string used in
different contexts in diffrent ways. This patch provides a wrapper
for msgcat::mc that trims "@@" and anything coming after it, whether
or not the string actually got translated.
Proposed-by: NHarri Ilari Tapio Liusvaara <hliusvaa@cc.hut.fi>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

* maint:
  git-gui: Don't delete send on Windows as it doesn't exist

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>

Currently the Git plumbing is not localized so it does not know how
to output weekday and month names that conform to the user's locale
preferences.  This doesn't fit with the rest of git-gui's UI as some
of our dates are formatted in Tcl and some are just read from the Git
plumbing so dates aren't consistently presented.

Since git-for-each-ref is presenting us formatted dates and it offers
no way to change that setting even in git 1.5.3.1 we need to first do
a parse of the text strings it produces, correct for timezones, then
reformat the timestamp using Tcl's formatting routines.

Not exactly what I wanted to do but it gets us consistently presented
date strings in areas like the blame viewer and the revision picker
mega-widget's tooltips.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Someone on #git today pointed out that the revision chooser's tooltips
are were being drawn with untranslated strings for the fixed labels we
include, such as "updated", "commit" and "remote".  These strings are
now passed through mc to allow them to be localized.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

* maint:
  git-gui: Trim trailing slashes from untracked submodule names
  git-gui: Assume untracked directories are Git submodules
  git-gui: handle "deleted symlink" diff marker
  git-gui: show unstaged symlinks in diff viewer

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>

* maint:
  git-gui: Avoid use of libdir in Makefile
  git-gui: Disable Tk send in all git-gui sessions
  git-gui: lib/index.tcl: handle files with % in the filename properly

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>

* maint:
  git-gui: Properly set the state of "Stage/Unstage Hunk" action
  git-gui: Fix detaching current branch during checkout
  git-gui: Correct starting of git-remote to handle -w option

Conflicts:

	git-gui.sh

If we have a failure executing msgfmt (such as the process just
crashes no matter what arguments you supply it because its own
installation is borked) we should stop the build process rather
than letting it continue along its merry way as if the .msg files
were created.
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>