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>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
MINGW converts an intial '/' in paths to the full Windows
path of MINGW's rootdir. Therefore, the result of the
build cannot be installed in another directory.
This is fixed by replacing the initial '/' by its octal
escape sequence that represents '/' in C strings. This
sequence avoids the path conversion.
Note, the Makefile contains the full path and can not be
used any longer to build git with a different prefix.
git may segfault if gitattributes contains an invalid
entry. A test is added to t0020 that triggers the segfault.
The parsing code is fixed to avoid the crash.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
If an external git command (not a shell script) was invoked with arguments
that contain spaces, these arguments would be split into separate
arguments. They must be quoted. This also affected installations where
$prefix contained a space, as in "C:\Program Files\GIT". Both errors can
be triggered by invoking
git hash-object "a b"
where "a b" is an existing file.
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>
By moving the logo into its own procedure we can use it in
multiple locations within the UI, but still load it only if
the logo is going to be used by the application.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This commit teaches git-gui to accept versions with annotations
that start with text and optionally end with a dot followed by
a number.
This is needed by the current versioning scheme of msysgit,
which uses versions like 1.5.3.mingw.1. However, the changes
is not limited to this use case. Any version of the form
<numeric version>.<anytext>.<number> would be parsed and only
the starting <numeric version> used for validation.
[sp: Minor edit to remove unnecessary group matching]
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some workflows allow the user to forcefully update a remote branch,
such as in a "proposed updates" (aka "pu") branch where the branch
is rewound and rebuilt on a daily basis against the current master
branch. In such a case the "--force" or leading + must be used to
make git-push execute anyway, even though it may be discarding one
or more commits on the remote side.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
git-gui: Don't crash when starting gitk from a browser session
git-gui: Allow gitk to be started on Cygwin with native Tcl/Tk
Conflicts:
git-gui.sh
If the user has started git-gui from the command line as a browser
we offer the gitk menu options but we didn't create the main status
bar widget in the "." toplevel. Trying to access it while starting
gitk just results in Tcl errors.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
gitk expects $env(GIT_DIR) to be valid as both a path that core Git
and Tcl/Tk can resolve to a valid directory, but it has no special
handling for Cygwin style UNIX paths and Windows style paths. So
we need to do that for gitk and ensure that only relative paths are
fed to it, thus allowing both Cygwin style and UNIX style paths to
be resolved.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Derive the git installation dir from the executable path
and directly use the Win32 API to open the HTML file. This
avoids the mingw layer and command line escaping problems,
which caused the previous implementation to fail if spaces
were contained in the path to git.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
