Previously we allowed users to tweak their font weight to be bold by
setting it manually in their ~/.gitconfig prior to starting git-gui.
This was broken in ae0754ac9a when
Simon set the font weight to normal by default, overridding whatever
we found from the ~/.gitconfig file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The "--statistics" option was ignored so far; no longer. Now we have
a message similar to that of msgfmt. (Untranslated, though ;-)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Do not generate translations when the translated message is empty.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As Christian Stimming pointed out, entries which are "fuzzy" need to
be checked by human translators, and cannot be used.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a translation string uses a format character we don't have an
argument for then it may throw an error when we attempt to format
the translation. In this case switch back to the default format
that comes with the program (aka the English translation).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm seeing a lot of silent failures from git-update-index on
Windows and this is leaving the index.lock file intact, which
means users are later unable to perform additional operations.
When the index is locked behind our back and we are unable to
use it we may need to allow the user to delete the index lock
and try again. However our UI state is probably not currect
as we have assumed that some changes were applied but none of
them actually did. A rescan is the easiest (in code anyway)
solution to correct our UI to show what the index really has
(or doesn't have).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In particular many screw-ups after po regeneration were fixed.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The most important changes are:
- Git version cannot be determined... (lost in 57364320bf)
- git-gui: fatal error
Some changes need the second opinion (search for TOVERIFY), some changes are just copies (search for "carbon copy").
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Git progress bars from tools like git-push and git-fetch use CR
to skip back to the start of the current line and redraw it with
an updated progress. We were doing this in our Tk widget but had
failed to skip the CR, which Tk doesn't draw well.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Post Git 1.5.3 a new style progress bar has been introduced that
uses only one line rather than two. The formatting of the completed
and total section is also slightly different so we must adjust our
regexp to match. Unfortunately both styles are in active use by
different versions of Git so we need to look for both.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If git-write-tree fails (such as if the index file is currently
locked and it wants to write to it) we were not getting the error
message as $tree_id was always the empty string so we shortcut
through the catch and never got the output from stderr.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-config won't honor any options after --list. We must supply
the --global option in front of --list if we really want to load
the global configuration options.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I keep forgetting to include TCLTK_PATH when I build git-gui on some
systems. Placing that rule (among others) into a config.mak makes it
easier to compile the application the same way every time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently native Tcl/Tk on Windows is using \ as the return value
from [file separator] but [file normalize] on that same system is
using / rather than \ to represent a directory separator. I really
think that is nuts, but its what is happening.
So we can actually just hardcode our separator to / as all systems
we support (Windows, Mac OS X, UNIX) use /.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user tries to clone a Git repository that is actually a
workdir of another repository (by way of contrib git-new-workdir)
then the contents of .git is a series of Windows .lnk files which
Tcl can't read if this is a native Tcl process. To read the real
objects directory we need to resolve the link to that location.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows its better to use a shortcut (.lnk file) over a batch
script (.bat) as we can specify the icon file for the .lnk and
thus have these git specific objects appear on the desktop with
that git specific icon file.
Unfortunately the authors of Tcl did not bless us with the APIs
needed to create shortcuts from within Tcl. But Microsoft did
give us Windows Scripting Host which allows us to execute some
JavaScript that calls some sort of COM object that can operate
on a .lnk file.
We now build both Cygwin and non-Cygwin "desktop icons" as proper
Windows .lnk files, using the "Start in" property of these files
to indicate the working directory of the repository the user wants
to launch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows using the native Tcl/Tk the copyright header is
being read from the script using the system encoding, which
may not be utf-8. This causes the multi-byte copyright symbol
(which is actually encoded as utf-8) to read as two characters
and not as a proper copyright symbol. Explicitly asking Tcl
to read this sequence of bytes as utf-8 corrects the issue.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows we need to actually setup binds for the accelerator
keys, otherwise the OS doesn't respond to them when the user
presses the key combinations. Apparently we automatically get
these on Mac OS X when we configure the menu commands, but not
on Windows.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Although we are using a text widget here we really do not
want the end-user to be able to modify the text it displays.
So we need to disable it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We need to remove any variable traces we may have installed
when the panel is destroyed as the trace may attempt to use
a widget that no longer exists on this panel.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we show the repository chooser as the primary toplevel (".") we
now offer the major choices not just on the window as hyperlinks but
they also now are shown in the Repository menu, including the recent
repository list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Making a user click twice to select which action they want to perform
when starting git-gui is just wasting their time. Clicking once on a
radio button and then clicking again on the "Next >" button is quite
unnecessary.
Since the recent repository list is shown as a list of hyperlinks we
now offer the 3 basic startup actions as hyperlinks. Clicking on a
link will immediately jump to the next UI panel, saving the user time
as they don't need to click an additional button.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If git-gui is started outside a work tree the repository chooser
will offer a list of recently opened repositories. Clicking on
any list entry directly opens the repository.
The list of recently opened repositories is stored in the config
as the multi-valued option gui.recentrepo. If the list grows beyond
10 entries it will be truncated by removing one of the older entries.
Only repositories that are opened through the repository chooser
will get added to the recent list. Repositories opened from the
shell will not yet be added to the recent list, as users are likely
to have a way to easily return to the same directory via their shell.
[sp: This is actually a combined work from both Steffen and myself.
Most of the ideas are Steffen's, as is the basic outline of
the code, but any outstanding bugs are entirely my fault.]
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Using the new --null option added to git-config in git 1.5.3 we
can safely accept LFs that are embedded in configuration options.
This does require a completely different configuration file parser
then the pre 1.5.3 version as we are splitting on very different
values.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The parsing for the output of `git config --list` is the same for
both the global options and the current repository's options so we
can really just use the same parser between them.
I'm currently just refactoring the parser so we can use a different
one depending on the version of git available to us at runtime. My
next change will add support for 1.5.3's --null option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To better handle configuration options that contain LFs in their
values we want to use the new -z option available in git-config
version 1.5.3 and later. To configure load_config based upon the
git version we need to move thos below the git-version computation.
No logic changes yet, just a minor reordering of the code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The layout is changed to have the file lists at the left (Unstaged
Changes at the top, Staged Changes below it) and the diff window
at the right (with the commit area below it).
+----------+---------------------+
| Unstaged | Diff area |
| | |
| | |
| | |
+----------+ |
| Staged | |
| +---------------------+
| | Commit area |
| | |
+----------+---------------------+
The advantages are:
- The height of the file lists can be adjusted independently to
fit the files that they contain.
- The diff viewer is higher.
On wide screens it is ok that the main window is now generally
wider, too.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
An Italian glossary was also added. Some changes:
* commit (verb): (creare una) nuova revisione
* commit (noun): revisione
* checkout: attivazione
* tracking branch: duplicato locale di ramo remoto
* repository: archivio
* some terms are used with more consistency
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The wrapper adds the directory it is installed in to PATH.
This is required for the git commands implemented in shell.
git-gui fails to launch them if PATH is not modified.
The wrapper script also accepts an optional command line
switch '--working-dir <dir>' and changes to <dir> before
launching the actual git-gui. This is required to implement
the "Git Gui Here" Explorer shell extension.
As a last step the original git-gui script is launched,
which is expected to be located in the same directory
under the name git-gui.tcl.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn's git-gui Makefile supports the pure tcl replacement
for msgfmt if setting NO_MSGFMT. This patch sets the NO_MSGFMT
for msysgit.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This commit modifies PATH to include a good guess where git
could be found. The first location to search for executable is
the directory git-gui is installed in. This is a good guess for
a sane installation.
Even if git is not available in PATH, git-gui is now able
to find it. Hence git-gui can be passed to wish as an absolute
path without caring about the environment.
We must modify PATH to be able to spawn shell based git commands.
For builtins it would be sufficient to located them and execute
them with their absolute path. But for shell based git commmands
PATH needs to be modified.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* cs/de:
git-gui: Update German translation, including latest glossary changes
git-gui: Incorporate glossary changes into existing German translation
git-gui: Update German glossary according to mailing list discussion
git-gui: Add more words to translation glossary
The titles for the staged and unstaged areas were usually opening
up too narrow by default, causing the text to be clipped by Tcl as
it tried to center the text in the middle of the available area.
This meant that users who were new to git-gui did not get to see
the entire header and may be unclear about what the different lists
are.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A Mac OS X UI convention is to have Cmd-, be the accelerator key
for the preferences window, which by convention is located in the
apple menu under a separator below the about command. We also now
call this "Preferences..." as that is the conventional term used
in English.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes the Fetch menu looks really odd, such as if you are in a
repository that has no remotes configured when you start git-gui.
Here we didn't have any items to add to the Fetch menu so it was a
tad confusing for the end-user to see an empty menu on the menu bar.
We now place all of the commands related to fetching and pushing of
changes into a single "Remote" menu. This way we have a better class
of bucket that we can drop additional remote related items into such
as doing a remote merge or editing the remote configuration specs.
The shortcuts to execute fetch/remote prune/push on existing remote
specifications are now actually submenus listing the remotes by name.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are updating the index to stage or unstage changes or reverting
files in the working directory we can use the progress handling parts
of our status bar to perform this display work, reducing the amount of
code duplication we have in the index handling module.
Unfortunately the status bar is still a strict approximation as it is
unable to know when git-update-index has processed the data we fed to
it. The progress bar is actually a progress of the pipe buffer filling
up in the OS, not of the actual work done. Still, it tells the user we
are working and that has some value.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most applications tend to have some sort of pretty image in the
about dialog, because it spruces the screen up a little bit and
makes the user happy about reading the information shown there.
We already have a logo in the repository selection wizard so we
can easily reuse this in the about dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The about dialog is getting somewhat long in size and will probably
only get more complex as I try to improve upon its display. As the
options dialog is even more complex than the about dialog we move
the about dialog into its own module to reduce the complexity of the
option dialog module.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
