The Tcl msgcat package doesn't detect the use of a multi-lingual language
pack on Windows 7. This means that a user may have their display language
set to Japanese but the system installed langauge was English.
This patch reads the relevent registry key to fix this before loading in
the locale specific parts of git-gui.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
The user might have got used to the order the remotes appeared previously.
Lets add the all entry last so the all entry does not confuse previous
users.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Tested-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
The --all option for git fetch was added in v1.6.6 so ensure we have a usable version before adding
the menu items.
Sometimes people use tearoff menus and these offset the entry indices by one.
Acked-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
The commandline fetch already has this option for some time. Since this
was not available at the time git gui was written lets implement it now.
Signed-off-by: Heiko Voigt <heiko.voigt@mahr.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
This is useful if you are directly working together with other
developers pushing feature branches on a shared remote. You typically
push feature branches to the remote so others can review. Once they are
satisfied and the branch is merged into the main branch it needs to be
deleted on the server.
Since we did not yet have a preselected default branch in the remote
delete dialog lets use the last merged branch if it is found on the
server.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
When starting git gui in a non-git directory it presents the user a
dialog which asks to create, clone or open a repository. The filedialogs
used to choose the path(s) would always default to the home directory of
the user. This patch changes this behavior and uses the current working
directory in which git gui was started as default.
This is useful in various cases. First being that the user starts the
gui in some directory and can go search to create, open or clone a
repository from there. Another use case is that tools like filemanager
context menues can transport a natural default when selected from a
folder.
Users who like to have their home folder as a default can fall back on
starting git gui with its working directory set to the home folder.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
If the list of remote/local branches is very long its inconvenient
to scroll down and find the selected branch. This patch makes the
widget automatically scroll down so its shown on the top.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
The selection of the branch to be pushed would be cleared when
the remote was changed. This seems to be dependent on the fact that
the selected content in the combobox was exported to the clipboard. It
was only apparent when using the new ttk widget.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
The fix in ca53c3f (Fix diff parsing for lines starting with "--" or "++",
2008-09-05) got a bug report from Johannes Sixt, that new files in the
index now looks like:
new file mode 100644
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+foo
The introduced problem was that the 'in-diff-header'-flag was unconditially
disabled. Now it is only disabled when a hunk line is detected. And also
re-enabled when we encounter a new diff header.
The second part solves also the issue reported by me for diffs with file
type changes (i.e. the ''error: Unhandled 2 way diff marker: {d}"', which
comes from the second 'diff --git' line).
Reported-by: Johannes Sixt <j.sixt@viscovery.net>
Reported-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
$s will be referenced in the error message. Which was broken since
"git-gui: Automatically update-index all included files before commit"
(bbe3b3b, 2006-11-16).
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Translating a SCM is tricky due to amount of jargon, so, I tried to
keep the wording consistent with both the German and Italian git
translations and the pt-BR translation of other SCMs.
Signed-off-by: Alexandre Erwin Ittner <alexandre@ittner.com.br>
This fixes git-gui failing to display untracked files that are listed
if core.excludefiles is set to ~/.gitexcludes
[PT: added expansion of core.excludesfile value by tcl]
Signed-off-by: Stefan Naewe <stefan.naewe@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
The hunk tag d_@ lost its blue forground color in "apply color information
from git diff output" (2010-10-22, 8f85599). But this tag was also used
for non-hunk content like untracked file mime types or git submodules.
Introduce a new tag for this type of content which has the blue forground
again.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
browser_path used to end with a slash, so the regexp matches the empty string
and therefore removes nothing.
Fix this.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Respect the conflict-marker-size attribute on paths when detecting merge
conflicts.
[PT: fixed problem with variable substitution in the regexps]
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git diff always outputs color reset commands, even when the color for the
current part is disabled (ie. normal). But the current ANSI-color parsing code
assumes that color start and reset commands appear in matching pairs.
Relax this assumption.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
This patch extracts the ANSI color sequences from git diff output and
applies these to the diff view window. This ensures that the gui view
makes use of the current git configuration for whitespace display.
ANSI codes may include attributes, foreground and background in a single
sequence. Handle this and support bold and reverse attributes. Ignore
all other attributes.
Suggested-by: Tor Arvid Lund <torarvid@gmail.com>
Suggested-by: Junio C Hamano <gitster@pobox.com>
Tested-by: Tor Arvid Lund <torarvid@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
The Tk text widget tab style is tabular where the first tab will align to
the first tabstop and if that position is left of the current location
then just a single character space is used. With the wordprocessor style
a tab moves the next character position to the next rightmost tabstop
as expected for viewing code.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui currently uses its own logic to determine the work-tree setting
but 'git rev-parse --toplevel' directly returns git's work-tree value
by calling get_git_work_tree() and is therefore always correct.
This fixes an inability to handle some repository configurations. In
particular where .git is a file containing a path to the real directory
(a cross-platform symbolic link).
To continue to support older versions than 1.7.0, setting the work-tree
by normalizing the --show-cdup value is more reliable as git-dir might be
outside the work-tree entirely.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Rather than attempting to trim off all the non-version number suffixes
from the 'git version' result, let us scan along from the beginning until
we find a non-numeric part and stop there. Any such dot-version number will
be compatible with the Tcl package version comparison command which is the
aim of this code.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Without any standard channels the trace option is pretty useless on Win32
unless you can show the Tk console which captures such output. This also
permits introspection of the running application to assist in debugging.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
It's a common case for Windows developers to have both Cygwin and msysGit
installed. Unfortunately, some scenarios also require to have Cygwin in PATH.
By default, Cygwin comes with nice.exe, while msysGit does not. Since git-gui
calls nice if it is in PATH, this results in Cygwin's nice.exe being called
from msysGit's git-gui. Mixing Cygwin and msysGit generally is not a good idea,
and in this particular case it causes differences not being correctly detected.
So we only call nice.exe on Windows if it is in the same directory as git.exe.
This way, this work-around does neither affect a pure Cygwin environment, or
the case when nice.exe will be shipped with msysGit at some point in time.
This fixes msysGit issue 394.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
On Windows the tcl script file will use the system encoding and attempting
to convert the copyright mis-encodes the string. Instead, keep the message
as ASCII and substitute in the correct unicode character when running.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
With Tk 8.5 the askpass utility can hang waiting for the wish shell
implicit event loop to exit. This patch uses an explicit event loop
to ensure correct application termination.
Reported-by: Anders Kaseorg <andersk@mit.edu>
Tested-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
When developing/testing we run git-gui.sh directly and the makefile
configured variables are not properly set. Configure the new shellpath
accessor to handle this case.
On Windows we may not find the shell so in this case revert to simply
executing the filter command without the shell intermediate.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
The textconv filters may include multiple arguments and may make use
of unix shell features. To maintain compatibility with 'git blame'
ensure these commands are passed through bash.
Reported-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
This does not appear to Windows users and can follow the form of the fatal
error messages near the top of the script file.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
On Windows stdout and stderr are not connected to anything so the usage
statement is never shown to the user when an error is made with a command
line like 'git gui browser'. Use a messagebox on windows.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
The themed panedwindow needs to have the sash position set after the
widget has been mapped therefore apply this setting in the Map event
binding. To avoid visible redraws as the application is constructed
the main window should be withdrawn until all the widgets have been added
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
If someone attempts to use an older version that Tk 8.4 the error was
masked by the lack of a mc command.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
On Windows the Control-C binding is used to copy and is mapped to the Tk
virtual event <<Copy>>. In the initial git-gui dialog this is also bound
as an accelerator for the Clone menu item. The effect is that both bindings
run, copying the text but resetting the clone page or switching to the clone
page when the user tries to copy text from one of the entry fields.
This patch avoids this by using Control-L instead for Windows only.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
When the user tried to create a desktop icon with git gui on cygwin
wscript was complaining about an unknown option and displaying the
non-native path as such.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
When creating a desktop shortcut from the gui the shortcut directly
starts wish with the git-gui script. In the msysgit development
environment some dll's reside in the mingw/bin directory which causes
that git can not start because libiconv2.dll is not found.
When using such a link the error is even more cryptic stating:
"child killed: unknown signal"
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
It has already been fixed in commit 454efb47 (git-gui (Win): make
"Explore Working Copy" more robust, 2009-04-01), but has been broken in
commit 21985a11 (git-gui: handle non-standard worktree locations,
2010-01-23) by accidentally replacing too much with a new variable.
The problem can be reproduced when starting git-gui from within a
subdirectory. The solution is to convert the path name, explorer.exe is
invoked with, to a platform native name.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Commit 21985a11 'git-gui: handle non-standard worktree locations' attempts
to use either GIT_WORK_TREE or core.worktree to set the _gitworktree
variable but these may not be set which leads to a failure to launch
gitk to review history. Use _gitdir to set the location for a standard
git layout where the parent of the .git directory is the working tree.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
This fixes issue 394 from msysgit. It seems that the Gnuwin32 project
provides a nice command but it returns a "not implemented" error. To
help users we now try to execute once and disable it in case it fails.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Update ja.po to match 2010-01-26 version of pot file.
Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The shortcut was not properly recognized previously.
Signed-off-by: Heiko Voigt <heiko.voigt@mahr.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In do_git_gui the path of the git executable has to be put into a
list, otherwise calling it will fail when when spaces are present
in its path.
Reported-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This patch enables the use of themed Tk widgets with Tk 8.5 and above.
These make a significant difference on Windows in making the
application appear native. On Windows and MacOSX ttk defaults to the
native look as much as possible. On X11 the user may select a theme
using the TkTheme XRDB resource class by adding an line to the
.Xresources file. The set of installed theme names is available using
the Tk command 'ttk::themes'. The default on X11 is similar to the current
un-themed style - a kind of thin bordered motif look.
A new git config variable 'gui.usettk' may be set to disable this if
the user prefers the classic Tk look. Using Tk 8.4 will also avoid the
use of themed widgets as these are only available since 8.5.
Some support is included for Tk 8.6 features (themed spinbox and native
font chooser for MacOSX and Windows).
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This icon hasn't been used in git gui. I think it dates back to
the original set of icons I took from Paul Mackerras' prototype
that I turned into git gui.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This allows to quickly differentiate between new and modified files
in the index without selecting the file and looking at the diff.
Signed-off-by: Peter Oberndorfer <kumbayo84@arcor.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than juggling with the env var GIT_DIR around the invocation of
gitk, set it and GIT_WORK_TREE after finishing setup, ensuring that any
external tool works with the setup we're running with.
This also allows us to remove a couple of conditionals when running gitk
or git gui in a submodule, as we know that the variables are present and
have to be unset and reset before and after the invocation.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Refactor checking for a bare repository into its own proc, that relies
on git rev-parse --is-bare-repository if possible. For older versions of
git we fall back to a logic such that the repository is considered bare
if:
* either the core.bare setting is true
* or the worktree is not set and the directory name ends with .git
The error message for the case of an unhandled bare repository is also
updated to reflect the fact that the problem is not the funny name but
the bareness.
The new refactored proc is also used to disable the menu entry to
explore the working copy, and to skip changing to the worktree before
the gitk invocation.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Don't rely on the git worktree being the updir of the gitdir, since it
might not be. Instead, define (and use) a new _gitworktree global
variable, setting it to $GIT_WORK_TREE if present, falling back to
core.worktree if defined, and finally to whatever we guess the correct
worktree is. Getting core.worktree requires the config from the alleged
git dir _gitdir to be loaded early.
Supporting non-standard worktree locations also breaks the git-gui
assumption (made when calling gitk) that the worktree was the dirname of
$_gitdir and that, by consequence, the git dir could be set to the tail
of $_gitdir once we changed to the worktree root directory. Therefore,
we need to export a GIT_DIR environment variable set to the full,
normalized path of $_gitdir instead. We also skip changing to the worktree
directory if it's empty (i.e. if we're working on a bare repository).
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Multiple lines can be selected in the diff viewer and applied all
at once, rather than selecting "Stage Line For Commit" on each
individual line.
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To make it easier for users to deal with submodules, a special diff
popup menu has been added for submodules. The "Show Less Context"
and "Show More Context" entries have been removed, as they don't make
any sense for a submodule summary. Four new entries are added to the
top of the popup menu to gain access to more detailed information
about the changes in a submodule than the plain summary does offer.
These are:
- "Visualize These Changes In The Submodule"
starts gitk showing the selected commit range
- "Visualize These Changes In The Submodule"
starts gitk showing the whole submodule history of the current branch
- "Visualize All Branch History In The Submodule"
starts gitk --all in the submodule
- "Start git gui In The Submodule"
guess what :-)
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Doing so is much faster and gives the same output.
Here are some numbers:
$ time git submodule summary
real 0m0.219s
user 0m0.050s
sys 0m0.111s
$ time git diff --submodule
real 0m0.012s
user 0m0.003s
sys 0m0.009s
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When git-gui is run from a .git dir, _gitdir would be set to "." by
rev-parse, something that confuses the worktree detection.
Fix by expanding the value of _gitdir to pwd in this special case.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a diff looked like:
@@
context
-del1
-del2
and you wanted to stage the deletion 'del1', the generated patch
wouldn't apply because it was missing the line 'del2' converted to
context, but this line was counted in the @@-line
Signed-off-by: Jeff Epler <jepler@unpythonic.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When unstaging a partly staged file or submodule, the file_states
list was not updated properly (unless unstaged linewise). Its
index_info part did not contain the former head_info as it should
have but kept its old value.
This seems not to have had any bad effects but diminishes the value
of the file_states list for future enhancements.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When trying to run gitk on a branch name whose name matches a local
file, it will toss an error saying that the name is ambiguous. Adding
a pair of dashes will make gitk parse the options to the left of
it as branch names. Since wish eats the first pair of dashes we
throw at it, we need to add a second one to ensure they get through.
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the number of recent repo's gets to ten there can be a
situation where an item is removed from the .gitconfig file via
a call to git config --unset, but the internal representation of
that file (repo_config(gui.recentrepo)) is not updated. Then a
subsequent attempt to remove an item from the list fails because
git-gui attempts to call --unset on a value that has already
been removed. This leads to duplicates in the .gitconfig file,
which then also cause errors if the git-gui tries to --unset them
(rather than using --unset-all. --unset-all is not used because it
is not expected that duplicates should ever be allowed to exist.)
When loading the list of recent repositories (proc _get_recentrepos)
if a repo in the list is not considered a valid git reposoitory
then we should go ahead and remove it so it doesn't take up a slot
in the list (since we limit to 10 items). This will prevent a bunch
of invalid entries in the list (which are not shown) from making
valid entries dissapear off the list even when there are less than
ten valid entries.
See: http://code.google.com/p/msysgit/issues/detail?id=362
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As reported to msysGit (bug #340) it is possible to get some very
long error messages when updating the index. The use of a label to
display this prevents scrolling the output. This patch replaces the
label with a scrollable text widget configured to look like a label.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Providing multiple targets to force a rebuild is unnecessary
complication.
Avoid using a name that could conflict with future special
targets in GNU make (a leading period followed by uppercase
letters).
Cc: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Due to a bug in Tk, git-gui almost always (unless git-gui is closed
right after starting) produces an X window error message on exit,
something like:
X Error of failed request: RenderBadPicture (invalid Picture parameter)
Major opcode of failed request: 150 (RENDER)
Minor opcode of failed request: 7 (RenderFreePicture)
Picture id in failed request: 0x3a000dc
Serial number of failed request: 1965
Current serial number in output stream: 1980
Respective Tk bug report is here:
http://sourceforge.net/tracker/?func=detail&atid=112997&aid=1821174&group_id=12997
This bug is triggered only when the send command is blocked via
rename send {} . The following patch re-enables send just before
quiting git-gui to suppress the error.
Signed-off-by: Jindrich Makovicka <makovick@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On MacOS raising a window causes the focus to be transferred
to it -- although it may actually be a bug in the Tcl/Tk port.
When this happens with the blame viewer tooltips, it makes
the interface less usable, because Entry and Leave handlers
on the text view cause the tip to disappear once the mouse
is moved even 1 pixel.
This commit makes the code raise the main window on MacOS
when Tk 8.5 is used. This version seems to properly support
wm transient by making the tip stay on top of the master,
so reraising the master does not cause it to disappear. Thus
the only remaining sign of problems is slight UI flicker
when focus is momentarily transferred to the tip and back.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows, git-gui suggests running the garbage collector if it finds
1 or more files in .git/objects/42 (as opposed to 8 files on other
platforms). The probability of that happening if the repo contains
about 100 loose objects is 32%. The probability for the same to happen
when searching 4 directories is only 8%, which is bit more reasonable.
Also remove $objects_limit from the message, because we already know
that we are above (or close to) that limit. Telling the user about
that number does not really give him any useful information.
The following octave script shows the probability for at least m*q
objects to be found in q subdirectories of .git/objects if n is the
total number of objects.
q = 4;
m = [1 2 8];
n = 0:10:2000;
P = zeros(length(n), length(m));
for k = 1:length(n)
P(k, :) = 1-binocdf(q*m-1, n(k), q/(256-q));
end
plot(n, P);
n \ q 1 4
50 18% 1%
100 32% 8%
200 54% 39%
500 86% 96%
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We already do the same when locally deleting a branch.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the main window is maximized, if the screen height is shorter (e.g.
Netbook screen 1024x600), both the partial commit pane and the status bar
are hidden. The diff pane is resizable, so that it can use less vertical
height, allowing the overall window to be shorter and still display both
the entire commit pane and status bar.
Signed-off-by: Vietor Liu <vietor@vxwo.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This fixes a bug introduced by the "display summary when showing diff of a
submodule" patch. It lead to a "no such variable" error when opening the
diff context menu while no diff was shown.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I often close git gui window when it is maximized, and when I reopen
it next time the it would usually become out of place (e.g. a huge
window with a top-left corner somewhere close to the center of the
screen). Fix it by storing and restoring wm state in config, as well
as setting wm state to normal before retrieving wm geometry info.
Signed-off-by: Alexey Borzenkov <snaury@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When quoting an arbitrary user string in Tcl, its better to use
[list ...] than to use {...}, in case the user string has spaces
or { embedded within it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When a submodule commit had already been staged and another commit had
been checked out inside the submodule, the diff always displayed the
submodule commit log messages between the last supermodule commit and
the working tree, totally ignoring the commit in the index.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When there is a large number of new or modified files,
"display_all_files" takes a long time, and git-gui appears to hang.
This change limits the number of files that are displayed. This
limit can be set as gui.maxfilesdisplayed, and is 5000 by default.
A warning is shown the first time the list of files is truncated
in this GUI session. Subsequent truncations are not mentioned to
the user.
Signed-off-by: Dan Zwell <dzwell@zwell.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user wants to delete a remote branch and selects the correct
"merged into" we should not warn that "Recovering deleted branches is
difficult". For local branches we do the same already.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As it is hard to say what changed in a submodule by looking at the hashes,
let's show the colored submodule summary instead.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
- detect more Tk.framework variants
- fix apple menu setup, use native preferences menu item
- don't set menu font
Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Also, the previous translations of the words 'tag' and 'merge' were
changed. Added translation of the 'Tool' submenu.
Thanks go to Alexander Gavrilov and Dmitry Potapov for proofreading
and suggestions.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui is using "git-read-tree -u" when cloning which doesn't
invoke the post-checkout hook as a plain git-clone would.
So git-gui must call the hook itself.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In several places merge.keepBackup is used i.s.o.
mergetool.keepBackup. This patch makes it all
consistent.
Signed-off-by: Ferry Huberts <ferry.huberts@pelagic.nl>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commit 584fa9cc introduced the global variable diff_empty_count, which
is used in diff.tcl. This variable wasn't declared anywhere which
resulted in an ugly error message box instead of the intended
informative message.
Signed-off-by: Joerg Bornemann <joerg.bornemann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This works around git-gui's error message
Cannot use funny .git directory: .
when started from the .git/ directory, which is useful in repositories
without any directories for the right click.
Now git-gui can be started via Windows Explorer shell extension (Git GUI
Here) from the .git/ directory.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Starting the Explorer from the git-gui menu "Explore Working Copy"
didn't work, when git-gui was started via Windows Explorer shell
extension (Git GUI Here) from a directory within the project.
The Explorer raised an error message like this:
Path "C:/somedir/worktree" is not available or not a directory
It worked when started from the project directory itself, because then
the path argument for the Explorer was just '.' (current directory)
without any problematic forward slashes.
To make it work, convert the path given as argument to explorer.exe to
its native format with backslashes.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui is using "git-read-tree -u" for checkout which doesn't
invoke the post-checkout hook as a plain git-checkout would.
So git-gui must call the hook itself.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Before calling the post-commit hook, the variable "pc_err" is cleared
while later only "pch_error" is used. "pch_error$cmt_id" only appeared in
"upvar"-Statements (which were changed to "global") and was removed.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Previously a hardcoded path $GIT_EXEC_PATH/../Documentation/ was used to
search for the documentation, when the user has asked for it via menu
"Help -> Online Documentation".
This didn't work for the default directory structure.
To find the path reliably, use the new git command line option, which
returns the correct path.
If the output of `git --html-path` is empty because git is not found or
the option is not yet supported in the installed git, the documentation
from kernel.org is launched. There is no additional guessing of the
right location of the installed docs.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
An "Application Error" was raised when trying to delete text from the
commit message field when no text was selected.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Properly spell "successful" and slightly rewrite a couple of strings
that actually say the same thing in order to reduce translation work.
Update .pot and .po files accordingly since no new translation is
required.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Mostly grammar, spelling and typography fixes, but also a few wording
enhancements here and there.
Signed-off-by: Sam Hocevar <sam@zoy.org>
Acked-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When a merge conflict occurs in a file with spaces in the filename,
git-gui showed wrongly "LOCAL: deleted".
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather shrink the input field for "Create New Repository" and "Open
Existing Repository" as it's already done for "Clone Existing
Repository".
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The git-gui menu item "Repository | Create Desktop Icon" creates a
shortcut (.lnk file) on the Windows desktop. The purpose of the
created shortcut is to make it easy for a user to launch git-gui
for a particular repo in the future.
A Windows user would expect to see git gui launch when they click
the shortcut; they would not expect (nor want) to see a cmd window
open and remain open in the background.
msysGit avoids opening a command window altogether when it's Git GUI
shortcut is used. Ideally, git on cygwin would also have shortcuts
that simply open the GUI, but as a first step, this change allows
the shell window to politely disappear after starting git gui as a
background process.
Signed-off-by: Phil Lawrence <prlawrence@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Recently the msysgit repository has got a '1.6.1-msysgit1'
tag, which, when used to build the git version, is not
handled gracefully by the git-gui version code.
This patch changes the regular expressions to fix it, and
removes the hardcoded 'rc' string. Now git-gui can accept
a version tail like '.foo123.GIT.bar.456.7.g89ab'
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the index update machinery and git diff happen to disagree
on whether a particular file is modified, it may cause git-gui
to enter an infinite index rescan loop, where an empty diff
starts a rescan, which finds the same set of files modified,
and tries to display the diff for the first one, which happens
to be the empty one. A current example of a possible disagreement
point is the autocrlf filter.
This patch breaks the loop by using a global counter to track
the auto-rescans. The variable is reset whenever a non-empty
diff is displayed.
Another suggested approach, which is based on giving the
--exit-code argument to git diff, cannot be used, because
diff-files seems to trust the timestamps in the index, and
returns a non-zero code even if the file is actually
unchanged, which essentially defeats the purpose of the
auto-rescan logic.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As pointed out in msysgit bug #181, when a non-locale encoding is
used for commits, post-commit status messages display the subject
incorrectly. It happens because the file handle is not properly
configured before the subject is read back.
This patch fixes it by factoring out the code that is used to setup
the output handle into a separate function, and calling it from
the reading code.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Acked-by: Robin Rosenberg <robin.rosenberg@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In dc871831(Only use GIT_CONFIG in "git config", not other programs),
GIT_CONFIG_LOCAL was rested in peace, in favor of not reading
/etc/gitconfig and $HOME/.gitconfig at all when GIT_CONFIG is set.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This file have been used locally for some time, and is near
completion. Will put an effort into completing it later on,
or just leave it as an excercise for other Norwegians.
Signed-off-by: Fredrik Skolmli <fredrik@frsk.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commits without an encoding header are supposed to
be encoded in utf8. While this apparently hasn't always
been the case, currently it is the active convention, so
it is better to follow it; otherwise people who have to
use commitEncoding on their machines are unable to read
utf-8 commits made by others.
I also think that it is preferrable to display the warning
about an unsupported value of commitEncoding more prominently,
because this condition may lead to surprising behavior and,
eventually, to loss of data.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Currently using '..' or '.' in the file path for gui blame
causes it to break, because the path is passed inside the
SHA:PATH spec to cat-file, which apparently does not understand
such items. As a result, cat-file returns nothing, and the
viewer crashes because of an "index out of range" error.
This commit adds a simple function that normalizes such paths.
I choose not to use [file normalize], because it uses some data
from the file system, e.g. dereferences symlinks, and creates
an absolute path, while blame may be used to inspect historical
information that bears no relation to the current filesystem state.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the destination repository is a mirror, this function goofed by still
passing a refspec to git-push. Now it notices that the remote is a mirror
and holds the refspec.
Signed-off-by: Mark Burton <markb@ordern.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since delete_this is an ordinary function, it
should not be passed to cb; otherwise it produces
errors when blame windows are closed. Unfortunately,
it is not noticeable when blame is shown in the
master window, so I missed this bug.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Tools menu is generally intended for commands that
affect the working directory or repository state. Thus,
the user would usually want to initiate rescan after
execution of a tool. This commit implements it.
In case somebody would want to avoid rescanning after
certain tools, it also adds an option that controls it,
although it is not made available through the Add dialog.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
While static commands are already useful, some tools need
additional parameters to reach maximum usability. This
commit adds support for passing them one revision name
parameter, and one arbitrary string. With this addition,
the tools menu becomes flexible enough to implement basic
rebase support:
[core]
editor = kwrite
[guitool "Rebase/Abort"]
cmd = git rebase --abort
confirm = yes
[guitool "Rebase/Continue"]
cmd = git rebase --continue
[guitool "Rebase/Skip Commit"]
cmd = git rebase --skip
confirm = yes
[guitool "Rebase/Start..."]
cmd = git rebase $ARGS $REVISION $CUR_BRANCH
title = Start Rebase
prompt = Rebase Current Branch
argprompt = Flags
revprompt = New Base
revunmerged = yes
Some of the options, like title or prompt, are intentionally
not included in the Add dialog to avoid clutter. Also, the
dialog handles argprompt and revprompt as boolean vars.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Due to the emphasis on scriptability in the git
design, it is impossible to provide 100% complete
GUI. Currently unaccounted areas include git-svn
and other source control system interfaces, TopGit,
all custom scripts.
This problem can be mitigated by providing basic
customization capabilities in Git Gui. This commit
adds a new Tools menu, which can be configured
to contain items invoking arbitrary shell commands.
The interface is powerful enough to allow calling
both batch text programs like git-svn, and GUI editors.
To support the latter use, the commands have access
to the name of the currently selected file through
the environment.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The rescan function receives a callback command
as its parameter, which is supposed to be executed
after the scan finishes. It is generally used to
update status. However, rescan may initiate a
loading of a diff, which always calls ui_ready after
completion. If the after handler is called before
that, ui_ready will override the new status.
This commit ensures that the after callback is
properly threaded through the diff machinery.
Since it uncovered the fact that force_first_diff
actually didn't work due to an undeclared global
variable, and the desired effects appeared only
because of the race condition between the diff
system and the rescan callback, I also reimplement
this function to make it behave as originally
intended.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
With the old implementation any system-wide options appear
to be set locally in the current repository. This commit
adds explicit handling of system options, essentially
interpreting them as customized default_config.
The difficulty in interpreting system options stems from
the fact that simple 'git config' lists all values, while
'git config --global' only values set in ~/.gitconfig,
excluding both local and system options.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When running under X, we try to set up a window icon by providing a
hand-crafted 16x16 Tk photo image equivalent to the .ico. Wrap in a
catch because the earlier Tcl/Tk 8.4 releases didn't provide the 'wm
iconphoto' command.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The blame builtin now supports automatic conversion of
metadata encoding. By default it is converted to the
character set specified by i18n.logoutputencoding.
Since gui blame expects the data in utf-8, it is
necessary to specify the desired encoding directly.
An old version of the blame command will simply
ignore the option.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The user might need to see the key before cloning a repository.
This patch makes the relevant menu item available in the Select
Repository/Clone dialog.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that the blame viewer has a search panel, it should be
taken into account by the focus transition code. Otherwise
showing a commit tip (by accidentally moving the mouse to
the text frame) causes the focus to transfer away from the
search field.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Previously, conflict markers were highlighted in two ways: (1) They
received a distinguishing color; and (2) they had the '+' removed at the
beginning of the line. However, by doing (2), a hunk that contained
conflict markers could not be staged or unstaged because the resulting
patch was corrupted. With this change we no longer modify the diff text
of a 2-way diff, so that "Stage Hunk" and friends work.
Note that 3-way diff of a conflicted file is unaffected by this change,
and '++' before conflict markers is still removed. But this has no negative
impact because in this mode staging hunks or lines is disabled anyway.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
OpenSSH allows specifying an external program to use
for direct user interaction. While most Linux systems
already have such programs, some environments, for
instance, msysgit, lack it. This patch adds a simple
fallback Tcl implementation of the tool.
In msysgit it is also necessary to set a fake value of
the DISPLAY variable, because otherwise ssh won't even
try to use SSH_ASKPASS handlers.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Generating a new SSH key or finding an existing one may
be a difficult task for non-technical users, especially
on Windows.
This commit adds a new dialog that shows the public key,
or allows the user to generate a new one if none were found.
Since this is a convenience/informational feature for new
users, and the dialog is mostly read-only, it is located
in the Help menu.
The command line used to invoke ssh-keygen is designed to
force it to use SSH_ASKPASS if available, or accept empty
passphrases, but _never_ wait for user response on the tty.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If an untracked text file is selected, then its contents are displayed
instead of a diff. If the file is large, then the following hint is
inserted at the top:
* Untracked file is 14774881 bytes.
* Showing only first 131072 bytes.
Why exactly 131072 bytes? With this patch it is 100000 bytes.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It did not delete the object, which is not very good.
Also, destroy may be fired up for subwindows, so we
should check %W.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
One of the largest deficiencies in the blame viewer at
the moment is the impossibility to search for a text
string. This commit fixes it by adding a Firefox-like
search panel to the viewer.
The panel can be shown by pressing F7 or clicking a
menu entry, and is hidden by pressing Esc. Find Next
is available through the F3 key.
Implementation is based on the gitk code, but heavily
refactored. It now also supports case-insensitive
searches, and uses the text box background color to
signal success or failure of the search.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On modern high-resolution monitors the blame viewer
window is very high, yet too narrow. This patch
makes it gravitate to a more sane resolution, which
takes the font size into account.
It also changes the default text view size to 80% of
the window, and slightly modifies the border decorations
for better appearance.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
0aea2842 (Make Ctrl-T safe to use for conflicting files) introduced a new
case, but forgot the '-' to indicate that it shares the body with the
subsequent case label.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As you can see, this particular code branch did not see a lot
of testing for some time now. Apologies for that.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Git-gui does not add most of the remotes to the 'push' menu
since they are missing the "Push" line in their remotespec.
In that case, removing the remote would end up with an error.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Before, the input boxes would not be sunken and would have larger border,
which is inconsistent with the rest of the inputboxes for repository
locations in the git-gui UI.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Instead, 'Location' is used to label such inputs; in the Clone dialog,
'Source' and 'Target' are also introduced to further clarify the situation.
The intent is to increase GUI consistency in the case location templates
(upcoming) are used - then, other locators than URL may be used.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Especially for Windows users used to work with the Windows Explorer,
it is very useful when after picking a repository (either opening
a local one or initializing/cloning a new one) in the "intro" window,
the explorer view of the working copy pops up along the standard
Git GUI window, so that the users can, well, actually work with
the repository.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Especially when cloning is finished, the Git GUI window pops up,
but there is not really much one can do within it - there needs to be
a way to easily start exploring and working with the new working copy
using the standard system interface: explorer.exe on Windows, open on
MacOS/X and xdg-open as a fallback (all modern Linux desktops).
This might be also a post-clone option instead (possibly opening the window
automagically) but I believe that this might be useful also in other
situations, e.g. you don't have to keep the working copy window around
if you work in multiple repositories.
This operation will not make sense on bare repositories.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This patch removes git-gui specific webbrowser guessing and instead
relies on git web--browser to do the right thing, removing unnecessary
code duplication. New function start_browser encapsulates the browser
execution, for usage from other parts of code. This will also make
git-gui show the documentation menu item even in cases it might not
be able to start up a browser, these cases should be however only
very rare.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This allows the user to create repositories with arbitrary paths
on the server. The downside is that errorneously typed paths are
not caught but instead created remotely; YMMV.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We introduce new submenu Remote -> Remove Remote, allowing to remove
remotes. In the future, we might consider a confirmation popup to avoid
misclicks, but removing a remote is not very lossy operation.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When a remote is being added, it can also be automatically either fetched
or initialized and pushed; this patch adds capability for initializing
of local and ssh repositories. This also of course leaves a lot of space
for further customization features, like individually turning the
initialization phase on/off or tuning attributes of the remote
repository; I consider that out of scope of this patch, however.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The meat of the routines is now separated to add_fetch_entry() and
add_push_entry(). This refactoring will allow easy implementation of adding
individual remotes later.
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Currently, it was not really clear what all does this perform. We rename
"Delete..." to "Delete Branch..." (since this does not delete the remote
as a whole) and relabel the window from "Delete Remote Branch" to "Delete
Branch Remotely" (since the action also involves pushing the delete out).
Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When git gui processes a reply from aspell it explicitly ignores an empty
line. The Windows version of aspell, however, terminates lines with CRLF,
but TCL's 'gets' does not remove CR, hence, a "visibly" empty line was not
actually recognized as empty. With this change we explicitly trim off
whitespace before the line is further processed.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A previous patch added a check for conflict markers, which
is done when the file is about to be staged due to a click
on the icon. However, pressing Ctrl-T still immediately
stages the file without confirmation. This patch fixes it.
The check requires a loaded diff, so staging multiple files
at once won't work if they are unmerged.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a merge tool was invoked on a conflicted file and the tool completed,
then the conflicted file was staged automatically. However, the fact that
the user closed the merge tool cannot be understood as the unequivocal
sign that the conflict was completely resolved. For example, the user
could have decided to postpone the resolution of the conflict, or could
have accidentally closed the tool. We better leave the file unstaged and
let the user stage it explicitly.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If citool --nocommit is invoked we hide the Sign Off features, as
the commit message area is not editable. But we really want the
selection tied to the message area's editing ability.
Suggested-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On windows, git gui fails to correctly extract the aspell version
(experienced with aspell version 0.50.3) due to scilent white space at
the end of the version string. Trim the obtained version string to
work around this.
Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This restores functionality of the file icon for unmerged files.
Safety is enforced by loading the diff and checking for lines
that look like conflict markers. If such lines are found, or
the conflict involves deletion and/or symlinks, a confirmation
dialog is presented. Otherwise, the icon immediately stages the
working copy version of the file.
Includes a revert of 2fe5b2ee42
(Restore ability to Stage Working Copy for conflicts)
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Encoding menu construction does almost a hundred of encoding
resolutions, which with the old implementation led to a
small but noticeable delay.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add a submenu to allow dynamically changing the encoding to use
for diffs. Encoding settings are remembered while git-gui runs.
The rules are:
1) Encoding set for a specific file overrides gitattributes.
2) Last explicitly set value of the encoding overrides gui.encoding
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To make encoding selection easier, add a menu that
lists available encodings to the Options window.
Menu structure is borrowed from Firefox.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
- Make diffs and blame default to the system (locale)
encoding instead of hard-coding UTF-8.
- Add a gui.encoding option to allow overriding it.
- gitattributes still have the final word.
The rationale for this is Windows support:
1) Windows people are accustomed to using legacy encodings
for text files. For many of them defaulting to utf-8
will be counter-intuitive.
2) Windows doesn't support utf-8 locales, and switching
the system encoding is a real pain. Thus the option.
This patch also adds proper encoding conversion to Apply Hunk/Line.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most commits have author name encoded in UTF-8, but the incremental
blame output dumps raw bytes and doesn't give us the encoding header
from the commit. Rather than fixing up tooltip data after we have
viewed that particular commit in the blame viewer we can assume all
names are in UTF-8.
This is still going to cause problems when the author name is not
encoded in UTF-8, but the only (efficient) way to solve that is to
add an "encoding" header to the blame --incremental mode output,
as otherwise we need to run `git cat-file commit $sha1` for each
and every commit identified and that would be horribly expensive
on any platform.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most folks using git-gui on internationalized files have complained
that it doesn't recognize UTF-8 correctly. In the past we have just
ignored the problem and showed the file contents as binary/US-ASCII,
which is wrong no matter how you look at it.
This really should be a per-file attribute, managed by .gitattributes,
so we now pull the "encoding" attribute data for the given path from
the .gitattributes (if available) and use that, falling back to UTF-8
if the attributes are unavailable, git-check-attr is broken, or an
encoding for this path not specified.
We apply the encoding anytime we show file content, which currently
is limited to only the diff viewer and the blame viewer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user started git-gui as "git citool --nocommit" then they
don't need the new commit / amend commit radio buttons, or the sign
off button in the UI. Rather than use up space with options the
user cannot activate they are simply not installed into the UI.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
- Make citool return nonzero exit code if it did not commit.
- Add a mode where it does not actually commit and simply
exits with zero code. Commit message is either disabled,
or simply dumped to GITGUI_EDITMSG before exiting.
- Add an option to immediately start it in amend mode.
Rationale:
1) Use 'git citool --nocommit' instead of mergetool in scripts.
2) Use 'git citool --amend' to edit commits while rebasing.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
For translations, it is almost always impossible to correctly translate
parts of sentences in almost any other language. Hence, messages like this
must be re-organized into full sentences.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <sop@google.com>
Tools like rerere leave files marked as conflicts in the index,
while actually resolving them in the working copy. Also, some
people like to use an external editor to resolve conflicts.
This patch restores functionality previously removed in
commit 617ceee653 by adding a new context menu item.
It still ensures that the user does not stage conflicting files
accidentally by clicking on the icon instead of the name.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <sop@google.com>
Make Blame Parent Commit and Show History Context work
properly for lines blamed on the working copy.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <sop@google.com>
Languages like Lua and SQL use "--" to mark a line as commented out.
If this appears at column 0 and is part of the pre-image we may see
"--- foo" in the diff, indicating that the line whose content is
"-- foo" has been removed from the new version.
git-gui was incorrectly parsing "--- foo" as the old file name
in the file header, causing it to generate a bad patch file when
the user tried to stage or unstage a hunk or the selected line.
We need to keep track of where we are in the parsing so that we do
not misread a deletion or addition record as part of the header.
Reported-by: Alexander Gladysh <agladysh@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add special handling for displaying diffs of modified/deleted,
and symlink/mode conflicts. Currently the display is completely
unusable for deciding how to resolve the conflict.
New display modes:
1) Deleted/Modified conflict: e.g.
LOCAL: deleted
REMOTE:
[diff :1:$path :3:$path]
2) Conflict involving symlinks:
LOCAL:
[diff :1:$path :2:$path]
REMOTE:
[diff :1:$path :3:$path]
In order to be able to display multiple diffs, this
patch adds a queue of commands to call.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If an untracked file is selected, F5 and other manual rescan synonyms
would try to select a tracked file instead. Also, clicking on an icon
in the unstaged changes list skips over untracked files, unless the
file clicked is untracked itself.
The objective is to make it easier to ignore untracked files showing
up in the Unstaged Changes list, and ensure that no modifications
to tracked objects are left unstaged.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Generalize the next_diff system, and implement auto-reselection
for merge tool resolution and reshow_diff. Also add auto-selection
of diffs after rescan, if no diff is already selected.
New auto-select rules:
- Rescan auto-selects the first conflicting file, or if none
a modified tracked file, if nothing was selected previously.
- Resolving a conflict auto-selects the nearest conflicting
file, or nothing if everything is resolved.
- Staging the last remaining hunk auto-selects the nearest
modified staged file.
- Staging a file through its icon auto-selects the nearest file.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Support _U (local deleted, remote modified) and
UT (file type changed in conflict) modes.
Note that 'file type changed' does not refer to
changes in the executable bit, instead it denotes
replacing a file with a link, or vice versa.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add native support for Araxis Merge, WinMerge and Perforce merge.
Custom merge tools are not implemented by mergetool.tcl; besides,
native support allows constructing the command lines in a more
intelligent way.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Prevent staging files with conflict markers by clicking
on the icon in the 'Unstaged Changes' list. Instead, pretend
that the user clicked the name, and show the diff.
Originally it made some sense to allow staging conflicting
files, because git-gui did not provide any tools to resolve
them from within the GUI. But now that we have added mergetool
capabilities, it is more likely to cause accidental and
non-undoable errors.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Adds an item to the diff context menu in conflict mode,
which invokes a merge tool for the selected file. Tool
command-line handling code was ported from git-mergetool.
Automatic default tool selection and custom merge tools
are not supported. If merge.tool is not set, git-gui
defaults to meld.
This implementation uses a checkout-index hack in order
to retrieve all stages with autocrlf and filters properly
applied. It requires temporarily moving the original
conflict file out of the way.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the file has merge conflicts, show a special version of the
diff context menu, which includes conflict resolution commands
instead of Stage Hunk/Line. This patch only supports resolving
by discarding all sides except one.
Discarding is the only way to resolve conflicts involving symlinks
and/or deletion, excluding manual editing.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Escape '$', because otherwise git-gui crashes while
trying to load malformed Japanese localization strings.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Staging hunks without context does not work, because line number
information would have to be recomputed for individual hunks.
Since it is already possible to stage individual lines using
'Stage Line for Commit', zero context diffs are not really
necessary for git gui.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add a command-line option to make git gui blame automatically
scroll to a specific line in the file. Useful for integration
with other tools.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Invoke diff-tree between the commit and its parent,
and use the hunks to fix the target line number,
accounting for addition and removal of lines.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add a context menu item that switches the view to the
parent of the commit under cursor. It is useful to see
how the file looked before the change, and find older
changes in the same lines.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add a context menu command to load commits
that are within a certain time range from the
selected commit into gitk.
It can be useful for understanding of the code,
especially if the repository is imported from
a VCS that does not support atomic commits.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The new execdir is two levels below the root directory, while
the old execdir 'bin' was only one level below. This commit
adapts the discovery of oguilib that uses relative paths
accordingly. We determine whether we have the extra level in the same
way in which the Makefile defines sharedir, i.e. whether the last
directory part is 'git-core'.
Inspired-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This should help tranlators that need to reorder words and strings.
Original explanation by Christian Stimming.
Also remove unneeded backslashes.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This updates Japanese translation to match the updated git-gui.pot.
Signed-off-by: しらいしななこ <nanako3@lavabit.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui needs bindir in PATH to be able to run 'git'. bindir
however is not necessarily in PATH if started directly through a
Windows shortcut. Therefore, we used to add the directory
git-gui is located in. But with the new 'libexec/git-core'
layout this directory is no longer identical to bindir.
This commit modifies the wrapper script to discover the bindir
and add it to PATH.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Instead of using an absolute path, git-gui can discover its
gui library using a relative path from execdir. We want to
use the relative path discovery on MinGW to avoid issues
with translation of absolute paths.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We always wanted the library for git-gui to install into the
$prefix/share directory, not $prefix/libexec/share. All of
the files in our library are platform independent and may
be reused across systems, like any other content stored in
the share directory.
Our computation of where our library should install to was broken
when git itself started installing to $prefix/libexec/git-core,
which was one level down from where we expected it to be.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Back in 15430be5a1 ("Look for gitk in $PATH, not $LIBEXEC/git-core")
git-gui learned to use [_which gitk] to locate where gitk's script
is as Git 1.6 will install gitk to $prefix/bin (in $PATH) and all
of the other tools are in $gitexecdir.
This failed on Windows because _which adds the ".exe" suffix as it
searches for the program on $PATH, under the assumption that we can
only execute something from Tcl if it is a proper Windows executable.
When scanning for gitk on Windows we need to omit the ".exe" suffix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It is especially useful for Stage/Unstage Line, because
they invoke full state scan and diff reload, which originally
would reset the scroll position to the top of the file.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It was positioned incorrectly (offset by one position)
if the menu had a tear-off handle.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Assume that we want to commit these states:
Old state == HEAD Intermediate state New state
--------------------------------------------------------
context before context before context before
old 1 new 1 new 1
old 2 old 2 new 2
context after context after context after
that is, want to commit two changes in this order:
1. transform "old 1" into "new 1"
2. transform "old 2" into "new 2"
[This discussion and this patch is about this very case and one other case
as outlined below; any other intermediate states that one could imagine are
not affected by this patch.]
Now assume further, that we have not staged and commited anything, but we
have already changed the working file to the new state. Then we will see
this hunk in the "Unstaged Changes":
@@ -1,4 +1,4 @@
context before
-old 1
-old 2
+new 1
+new 2
context after
The obvious way to stage the intermediate state is to apply "Stage This
Line" to "-old 1" and "+new 1". Unfortunately, this resulted in this
intermediate state:
context before
old 2
new 1
context after
which is not what we wanted. In fact, it was impossible to stage the
intermediate state using "Stage Line". The crux was that if a "+" line was
staged, then the "-" lines were converted to context lines and arranged
*before* the "+" line in the forged hunk that we fed to 'git apply'.
With this patch we now treat "+" lines that are staged differently. In
particular, the "-" lines before the "+" block are moved *after* the
staged "+" line. Now it is possible to get the correct intermediate state
by staging "-old 1" and "+new 1". Problem solved.
But there is a catch.
Noticing that we didn't get the right intermediate state by staging
"-old 1" and "+new 1", we could have had the idea to stage the complete
hunk and to *unstage* "-old 2" and "+new 2". But... the result is the same.
The reason is that there is the exact symmetric problem with unstaging the
last "-" and "+" line that are in adjacent blocks of "-" and "+" lines.
This patch does *not* change the way in which "-" lines are *unstaged*.
Why? Because if we did (i.e. move "+" lines before the "-" line after
converting them to context lines), then it would be impossible to stage
this intermediate state:
context before
old 1
new 2
context after
that is, it would be impossible to stage the two independet changes in the
opposite order.
Let's look at this case a bit further: The obvious way to get this
intermediate state would be to apply "Stage This Line" to "-old 2" and
"+new 2". Before this patch, this worked as expected. With this patch, it
does not work as expected, but it can still be achieved by first staging
the entire hunk, then *unstaging* "-old 1" and "+new 1".
In summary, this patch makes a common case possible, at the expense that
a less common case is made more complicated for the user.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To "Stage/Unstage Line" we construct a patch that contains exactly one
change (either addition or removal); the hunk header was forged by counting
the old side and adjusting the count by +/-1 for the new side. But when we
counted the context we never counted the changed line itself. If the hunk
had only one removal line and one line of context, like this:
@@ -1,3 +1,2 @@
context 1
-removal
context 2
We had constructed this patch:
@@ -1,2 +1,1 @@
context 1
-removal
context 2
which does not apply because git apply deduces that it must apply at the
end of the file. ("context 2" is considered garbage and ignored.) The fix
is that removal lines must be counted towards the context of the old side.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In Git 1.6 and later gitk is in $prefix/bin while git-gui and all
of the other commands are in $gitexecdir, which is typically not
the same as $prefix/bin. So we cannot launch $gitexecdir/gitk and
expect it to actually start gitk properly.
By allowing git-gui to locate the script via $PATH and then using
exactly that path when we source it during the application start
we can correctly run gitk on any Git 1.5 or later.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add a context menu item to invoke blame -C -C -C on a chunk
of the file. The results are used to update the 'original
location' column of the blame display.
The chunk is computed as the smallest line range that covers
both the 'last change' and 'original location' ranges of the
line that was clicked to open the menu.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Currently 'git-gui blame' does not kill its back-end
process, hoping that it will die anyway when the pipe
is closed. However, in some cases the process works
for a long time without producing any output. This
behavior results in a runaway CPU hog.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On huge repositories, -C -C can be way too slow to be
unconditionally enabled, and it can also be useful to control
its precision.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apply the work-around for checking the executable
permission of hook files not only on Cygwin, but on
Windows in general.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that MERGE_RR was moved out of .git/rr-cache/, we have to delete
it somewhere else. Just in case somebody wants to use a newer git-gui
with an older Git, the file .git/rr-cache/MERGE_RR is removed, too (if
it exists).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now, as in all OSX apps, there is only one quit menu entry.
It's automatically in the wish menu and calls ::tk::mac::Quit when used.
Signed-off-by: Soeren Finster <sf@9by6.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This adds a context menu entry below "Stage/Unstage Hunk" that stages or
unstages just the line under the mouse pointer.
This is by itself useful, for example, if there are unrelated changes in
the same hunk and the hunk cannot be split by reducing the context.
The feature can also be used to split a hunk by staging a number of
additions (or unstaging a number of removals) until there are enough
context lines that the hunk gets split.
The implementation reads the complete hunk that the line lives in, and
constructs a new hunk by picking existing context lines, removing unneeded
change lines and transforming other change lines to context lines. The
resulting hunk is fed through 'git apply' just like in the "Stage/Unstage
Hunk" case.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt noticed that if the last file in the list was staged, my
earlier patch would display the diff for the penultimate file, but show
the file _before_ that as being selected.
This was due to my misunderstanding the lno argument to show_diff.
This patch fixes the problem: lno is not decremented in the special case
to handle the last item in the list (though we still need to use $lno-1
to find the right path for the next diff).
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
Tested-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a text widget is asked the index at x,y with y == 0 or y == 1 it will
always return 1.0 as the nearest index, regardless of the x position.
This means that clicking the top 2 pixels of the Unstaged/Staged Changes
lists caused the state of the file there to be toggled. This patch
checks that the pixel clicked is greater than 1, so there is less chance
of accidentally staging or unstaging changes.
Signed-off-by: Richard Quirk <richard.quirk@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Suppose the "Unstaged Changes" pane contains a list of files, and one of
them is selected (i.e., that diff is currently being displayed). If one
clicks on the icon to stage the change, git-gui clears the diff and one
has to click on another filename to see the next diff in the list.
This patch changes that behaviour. If one clicks on the icon to stage
(or unstage) the file whose diff is being displayed, git-gui will move
on to the next filename in the list and display that diff instead of a
blank diff pane. If the selected file was at the end of the list, the
diff pane will display the previous diff instead; if the selected file
was the only one listed, the diff pane will become blank.
If no diff is currently being displayed, this patch changes nothing.
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In git-gui after clicking either on 'Create New Repository' or
'Open Existing Repository' the form elements aren't centered like
they are pretty much everywhere else in the app. At least when ran
on a mac, haven't checked on other platforms.
Using grid instead of pack seems to fix this.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user has put nowinsymlinks into their CYGWIN environment
variable any symlinks created by a Cygwin process (e.g. ln -s)
will not have the ".lnk" suffix. In this case workdir is still
a workdir, but our detection of looking for "info.lnk" fails
as the symlink is actually a normal file called "info".
Instead we just always use Cygwin's test executable to see if
info/exclude is a file. If it is, we assume from there on it
can be read by git-ls-files --others and is thus safe to use
on the command line.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Often new Git users want to know what commands git-gui uses to make
changes, so they can learn the command line interface by mimicking
what git-gui does in response to GUI actions. Showing the direct
commands being executed is easy enough to implement but this is of
little value to end-users because git-gui frequently directly calls
plumbing, not porcelain.
Since the code is already written and tested, its fairly harmless
to include. It may not help a new end-user, but it can help with
debugging git-gui or reverse-engineering its logic to further make
changes to it or implement another GUI for Git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are deleting a local branch from refs/heads/ we need to
make sure any associated configuration stored in .git/config is
also removed (such as branch.$name.remote and branch.$name.merge).
The easiest way to do this is to use git-branch as that automatically
will look for and delete configuration keys as necessary.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When creating new branches if branch.autosetupmerge is not set, or
is set to true or always and we have been given a remote tracking
branch as the starting point for a new branch we want to create the
necessary configuration options in .git/config for the new branch
so that a no argument git-pull on the command line pulls from the
remote repository's branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently aspell 0.50 does not recognize "$$cr master" as a command,
but instead tries to offer suggestions for how to correctly spell
the word "cr". This is not quite what we are after when we want
the name of the current dictionary.
Instead of locking up git-gui waiting for a response that may never
come back from aspell we avoid sending this command if the binary
we have started claims to be before version 0.60.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On startup, git-gui warns if there are many loose objects. It does so by
saying, e.g., that there are "approximately 768 loose objects". But isn't
"768" a very accurate number? Lets say "750", which (while still being a
very precise number) sounds much more like an estimation.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On some systems, brackets cannot be used as event details
(they don't have a keysym), so use +/- instead (both on
keyboard and keypad) and add ctrl-= as a synonym of ctrl-+
for convenience.
[sp: Had to change accelerator to show only "$M1T-="; the
original version included "$M1T-+ $M1T-=" but this is
not drawn at all on Mac OS X.]
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Bound to Ctrl/Cmd + left & right square brackets, depending on
your platform.
[sp: Added missing binds for . to allow shortcuts to work when
not focused in the commit message area.]
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Keeping POT up to date relative to the software is absolutely
necessary. What is unwarranted is updating language files at
the same time by running msgmerge without checking if there is
any outstanding translation work first. If we assume that the
translators do not have access to msgmerge, that is a good service
to them (the less they have to do, the better), but otherwise,
it is better to be leave po/${language}.po files alone.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Peter Karlsson pointed out there is no value in translating the
string "Apple", as this is used as the dummy label for the Apple
menu on Mac OS X systems.
The Apple menu is actually not the menu with the Apple corporate
logo, but the menu next to it, which shows the name of the
application and is typically called the application menu. Most users
of git-gui see this menu titled as "Git Gui". The actual label of
this menu comes from our Info.plist file and cannot be specified
by any other means. Translating this string in the Tcl PO files
is not necessary.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To prepare msg files for Tcl scripts, the command that is set to MSGFMT
make variable needs to be able to grok "--tcl -l <lang> -d <here>" options
correctly. This patch simplifies the tests done in git-gui's Makefile to
directly test this condition. If the test run does not exit properly with
zero status (either because you do not have "msgfmt" itself, or your
"msgfmt" is too old to grok --tcl option --- the reason does not matter),
have it fall back to po/po2msg.sh
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The width of the commit message text area is currently hard-coded
to 75 characters. This value might be not optimal for some projects.
For instance users who would like to generate GNU-style ChangeLog
file from git commit message might prefer commit messages of width
no longer than 70 characters.
This patch adds a global and per repository option "Commit Message
Text Width", which could be used to change the width of the commit
message text area.
Signed-off-by: Adam Piątyszek <ediap@users.sourceforge.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In several places, only the background colour is set to an explicit
value, sometimes even "white". This does not work well with dark
colour themes.
This patch tries to set the foreground colour to "black" in those
situations, where an explicit background colour is set without defining
any foreground colour.
Signed-off-by: Philipp A. Hartmann <ph@sorgh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
'make' shows:
MSGFMT po/zh_cn.msg 368 translated, 2 fuzzy, 1 untranslated message.
1. update the zh_cn.po and translate the remaining messages in chinese
2. correct some of the previously mis-translated messages
3. add a list of word interpretation in the head as a guideline for
subsequent updatings and translations
Signed-off-by: eric miao <eric.miao@marvell.com>
Acked-by: Xudong Guan <xudong.guan@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Mac OS X Tiger may have a msgfmt available but it doesn't understand
how to implement --tcl. Falling back to po2msg.sh on such systems
is a reasonable behavior.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user tries to commit their changes without actually staging
anything we used to display an informational dialog suggesting they
first stage those changes, then retry the commit feature.
Unfortunately I broke this in aba15f7 ("Ensure error dialogs always
appear over all other windows") and failed to fix it in the paper
bag fix that came one day after it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
git-gui: Focus insertion point at end of strings in repository chooser
git-gui: Avoid hardcoded Windows paths in Cygwin package files
git-gui: Default TCL_PATH to same location as TCLTK_PATH
git-gui: Paper bag fix error dialogs opening over the main window
When selecting a local working directory for a new repository or a
location to clone an existing repository into we now set the insert
point at the end of the selected path, allowing the user to type in
any additional parts of the path if they so desire.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we are being built by the Cygwin package maintainers we need to
embed the POSIX path to our library files and not the Windows path.
Embedding the Windows path means all end-users who install our Cygwin
package would be required to install Cygwin at the same Windows path
as the package maintainer had Cygwin installed to. This requirement
is simply not user-friendly and may be infeasible for a large number
of our users.
We now try to auto-detect if the Tcl/Tk binary we will use at runtime
is capable of translating POSIX paths into Windows paths the same way
that cygpath does the translations. If the Tcl/Tk binary gives us the
same results then it understands the Cygwin path translation process
and should be able to read our library files from a POSIX path name.
If it does not give us the same answer as cygpath then the Tcl/Tk
binary might actually be a native Win32 build (one that is not
linked against Cygwin) and thus requires the native Windows path
to our library files. We can assume this is not a Cygwin package
as the Cygwin maintainers do not currently ship a pure Win32 build
of Tcl/Tk.
Reported on the git mailing list by Jurko Gospodnetić.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most users set TCLTK_PATH to tell git-gui where to find wish, but they
fail to set TCL_PATH to the same Tcl installation. We use the non-GUI
tclsh during builds so headless systems are still able to create an
index file and create message files without GNU msgfmt. So it matters
to us that we find a working TCL_PATH at build time.
If TCL_PATH hasn't been set yet we can take a better guess about what
tclsh executable to use by replacing 'wish' in the executable path with
'tclsh'. We only do this replacement on the filename part of the path,
just in case the string "wish" appears in the directory paths. Most of
the time the tclsh will be installed alongside wish so this replacement
is a sensible and safe default.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the main window is the only toplevel we have open then we
don't have a valid grab right now, so we need to assume the
best toplevel to use for the parent is ".".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We really only support Aspell, so showing the compatibility line from
ispell is of little value to end users.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user has somehow managed to make us execute ispell instead
of aspell, even though our code is invoking aspell, and ispell is
not recognizing the aspell command line options we use to invoke
it then we don't want a giant usage message back from ispell.
Instead we show the ispell version number, letting the user know
we don't actually support that spell checker.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we feed a bad dictionary name to aspell on startup it may appear
to start (as Tcl found the executable in our $PATH) but it fails to
give us the version string. In such a case the close of the pipe
will report the exit status of the process (failure) and that is
an error in Tcl.
We now trap the subprocess failure and display the stderr message
from it, letting the user know why the failure is happening. We then
disable the spell checker, but keep our object instance so the user
can alter their preferred dictionary through the options dialog, and
possibly restart the spell checker.
I was also originally wrong to use "error" here for the display
of the problem to the user. I meant to use "error_popup", which
will open a message box and show the failure in a GUI context,
rather than killing git-gui and showing the message on the console.
Noticed by Ilari on #git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we reconnect to the spellchecker there is no reason to resetup
the binding for button 3 on our text widget to show the suggestion
list (if available).
Plus, by moving it out of _connect and into init we can now break
out of _connect earlier if there is something wrong with the pipe,
for example if the dictionary we were asked to load is not valid.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users may or may not be using aspell here. About the only thing
we are using that is aspell specific (and not supported by ispell
or an ispell variant) is some command line options when we start
up aspell, and a forced encoding of UTF-8. Both of these can be
corrected and/or cleaned up by users through an aspell wrapper
script, or through further improvements to git-gui. There is no
reason to require our translated strings to reference a specific
spell checker, especially if that spell checker implementation is
not very suitable for the language being translated.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we somehow managed to get our spellchecker instance created but
aspell wasn't startable we may not finish _connect and thus may
find one or more of our fields was not initialized in the instance.
If we have an instance but no version, there is no reason to show
a version to the user in our about dialog. We effectively have no
spellchecker available.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are opening an error dialog we want it to appear above all of
the other windows, even those that we may have opened with a grab
to make the window modal. Failure to do so may allow an error
dialog to open up (and grab focus!) under an existing toplevel,
making the user think git-gui has frozen up and is unresponsive,
as they cannot get to the dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
"git gui" would complain at launch if the local version of Git was
"1.5.4.2.dirty". Loosen the regular expression to look for either
"-dirty" or ".dirty", thus eliminating spurious warnings.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
And markup one missing string for translation.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We don't need to fill this entire horizontal cavity, it looks really
bad on some platforms to stretch the widget out to fill the window.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We don't want the list length, we need the string length.
Found due to a bad " character discovered in the text and
Tcl throwing 'unmatched open quote in list'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Many user friendly tools like word processors, email editors and web
browsers allow users to spell check the message they are writing
as they type it, making it easy to identify a common misspelling
of a word and correct it on the fly.
We now open a bi-directional pipe to Aspell and feed the message
text the user is editing off to the program about once every 300
milliseconds. This is frequent enough that the user sees the results
almost immediately, but is not so frequent as to cause significant
additional load on the system. If the user has modified the message
text during the last 300 milliseconds we delay until the next period,
ensuring that we avoid flooding the Aspell process with a lot of
text while the user is actively typing their message.
We wait to send the current message buffer to Aspell until the user
is at a word boundary, thus ensuring that we are not likely to ask
for misspelled word detection on a word that the user is actively
typing, as most words are misspelled when only partially typed,
even if the user has thus far typed it correctly.
Misspelled words are highlighted in red and are given an underline,
causing the word to stand out from the others in the buffer. This is
a very common user interface idiom for displaying misspelled words,
but differs from one platform to the next in slight variations.
For example the Mac OS X system prefers using a dashed red underline,
leaving the word in the original text color. Unfortunately the
control that Tk gives us over text display is not powerful enough
to handle such formatting so we have to work with the least common
denominator.
The top suggestions for a misspelling are saved in an array and
offered to the user when they right-click (or on the Mac ctrl-click)
a misspelled word. Selecting an entry from this menu will replace
the misspelling with the correction shown. Replacement is integrated
with the undo/redo stack so undoing a replacement will restore the
misspelled original text.
If Aspell could not be started during git-gui launch we silently eat
the error and run without spell checking support. This way users
who do not have Aspell in their $PATH can continue to use git-gui,
although they will not get the advanced spelling functionality.
If Aspell started successfully the version line and language are
shown in git-gui's about box, below the Tcl/Tk versions. This way
the user can verify the Aspell function has been activated.
If Aspell crashes while we are running we inform the user with an
error dialog and then disable Aspell entirely for the rest of this
git-gui session. This prevents us from fork-bombing the system
with Aspell instances that always crash when presented with the
current message text, should there be a bug in either Aspell or in
git-gui's output to it.
We escape all input lines with ^, as recommended by the Aspell manual
page, as this allows Aspell to properly ignore any input line that is
otherwise looking like a command (e.g. ! to enable terse output). By
using this escape however we need to correct all word offsets by -1 as
Aspell is apparently considering the ^ escape to be part of the line's
character count, but our Tk text widget obviously does not.
Available dictionaries are offered in the Options dialog, allowing
the user to select the language they want to spellcheck commit
messages with for the current repository, as well as the global
user setting that all repositories inherit.
Special thanks to Adam Flott for suggesting connecting git-gui
to Aspell for the purpose of spell checking the commit message,
and to Wincent Colaiuta for the idea to wait for a word boundary
before passing the message over for checking.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In the multiple message case we remove the word "messages" from the
statistics output of msgfmt as it looks cleaner on the tty when you
are watching the build process. However we failed to strip the word
"message" when only 1 message was found to be untranslated or fuzzy,
as msgfmt does not produce the 's' suffix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The strings we were showing from po2msg didn't exactly match those
of msgfmt's --statistics output so we didn't show quite the same
results when building git-gui's message files. Now we're closer
to what msgfmt shows (at least for an en_US locale) so the make
output matches.
I noticed that the fuzzy translation count is off by one for the
current po/zh_cn.po file. Not sure why and I'm not going to try
and debug it at this time as the po2msg is strictly a fallback,
users building from source really should prefer msgfmt.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If msgfmt fails with exit code 127 that typically means the program
is not found in the user's PATH and thus cannot be executed by make.
In such a case we can try to fallback to the Tcl based po2msg program
that we distributed with git-gui, as it does a "good enough" job.
We still don't default to po2msg.sh however as it does not perform
a lot of the sanity checks that msgfmt does, and quite a few of
those are too useful to give up.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the horizontal scrollbar isn't currently visible (because it has
not been needed) but we get an update to the scroll port we may find
the scrollbar window exists but the Tcl command doesn't. Apparently
it is possible for Tk to have partially destroyed the scrollbar by
removing the Tcl procedure name but still leaving the widget name in
the window registry.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Junio noticed this was incorrectly added in ISO-8859-1 but it should
be in UTF-8 (as the headers claim UTF-8, and our convention is to use
only UTF-8).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The code we use to test if a hook is executable or not differs on
Cygwin from the normal POSIX case. Rather then repeating that for
all three hooks we call in our commit code path we can place the
common logic into a global procedure and invoke it when necessary.
This also lets us get rid of the ugly "|& cat" we were using before
as we can now rely on the Tcl 8.4 feature of "2>@1" or fallback to
the "|& cat" when necessary.
The post-commit hook is now run through the same API, but its outcome
does not influence the commit status. As a result we now show any of
the errors from the post-commit hook in a dialog window, instead of on
the user's tty that was used to launch git-gui. This resolves a long
standing bug related to not getting errors out of the post-commit hook
when launched under git-gui.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
During i18n translation work this message was partially broken
by using "append" instead of "strcat" to join the two different
parts of the message together.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Under core Git the git-commit tool will invoke the commit-msg hook
if it exists and is executable to the user running git-commit. As
a hook it has some limited value as it cannot alter the commit, but
it can modify the message the user is attempting to commit. It is
also able to examine the message to ensure it conforms to some local
standards/conventions.
Since the hook takes the name of a temporary file holding the message
as its only parameter we need to move the code that creates the temp
file up earlier in our commit code path, and then pass through that
file name to the latest stage (where we call git-commit-tree). We let
the hook alter the file as it sees fit and we don't bother to look at
its content again until the commit succeeded and we need the subject
for the reflog update.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
gg_libdir is converted to an absolute Windows path on Cygwin,
but a later step attempts to prefix $DESTDIR to install to a
staging directory. Explicitly separate the uses of gg_libdir for
these two purposes so installation to $DESTDIR will work.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we apply a hunk in either direction this may change the file's
status. For example if a file is completely unstaged, and has at
least two hunks in it and the user stages one hunk the file will
change from "Modified, not staged" to "Portions staged for commit".
Resetting the file path causes our trace on this variable to fire;
that trace is used to update the file header in the diff viewer to
the file's current status.
Noticed by Johannes Sixt.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Often users setup a few source files and get a project rolling
before they create a Git repository for it. In such cases the
core Git tools allow users to initialize a new repository by
simply running `git init` at the desired root level directory.
We need to allow the same situation in git-gui; if the user is
trying to make a new repository we should let them do that to any
location they chose. If the directory already exists and already
has files contained within it we still should allow the user to
create a repository there. However we still need to disallow
creating a repository on top of an existing repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Here are some of the choices made to translate Git Gui to french:
- commit -> "commit" (noun) or "commiter" (verb)
- stage (index) -> "pré-commit" (noun) or "pré-commiter" (verb)
- (re)scan -> "(re)synchroniser"
- reset -> "réinitialiser"
- checkout -> "emprunt" (noun) or "emprunter" (verb)
- revision expression -> "expression de révison"
I am not completely happy with these, but it's a start...
[sp: Inserted a missing LF in message on line 466]
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Change translation of "clone" back to "klonen" because "kopieren" is a
much broader term than this particular git action.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I broke this extremely cool feature in 1ac17950,
but it is rather easy to fix this. Sorry for that.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
"revert" translated as "verwerfen".
"hunk" translated as "Kontext".
Several menu items reworded to be shorter.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Concatenating commit log messages from multiple commits works better
when all of the commits end with a clean line break.
Its good to be strict in what you create, and lenient in what you
accept, and since we're creating here, we should always try to
Do The Right Thing(tm).
Signed-off-by: Bernt Hansen <bernt@alumni.uwaterloo.ca>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The mapping of Windows vs Cygwin/Posix paths is arbitrary and not knowable
from the Posix side, so logic to determine whether to use relative paths
to locate the git-gui library just does not work on Cygwin. Fix this to
unconditionally use absolute path on Cygwin. (This fixes a regression
from 1.5.4).
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt pointed out the diff headers "old mode ..." and
"new mode ..." were not being parsed properly by git-gui. We
now include them in the diff viewer for a file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
"Stage/Unstage Hunk" is probably the most frequently used command of the
patch context menu *and* it is not available in some other form than
the context menu. Therefore, it should go to the top. "Less Context" and
"More Context" entries are also not easily available otherwise, and are
therefore, moved second. The other entries are available via key strokes
(Copy, Paste, Refresh) or rarly used (Font Size, Options) and can go last.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Previusly, there was only a 16x16 image, which looked very distorted.
Here we add a 32x32 version, and also make the image sharper.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The install-sh script as shipped with automake requires a space between
the -m switch and its argument. Since this is also the regular way of
doing it with other install implementations this change inserts the
missing space.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Any program using getopt or getopt_long will stop processing options
once a non-option argument has been encountered, if POSIXLY_CORRECT is
set. Therefore, reorder the command-line arguments to put options
first, so that the msgfmt call works in this scenario.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.ath.cx>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Aaron Digulla suggested we bind Ctrl-T or Cmd-T to "Stage To Commit"
menu action so it can be easily accessed from the keyboard.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
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>
When displaying the name of the application in window titles
and menu options (e.g. "About [appname]") we would prefer to
call ourselves "Git Gui" over "git-gui" as the former name is
now being actively used in the Mac OS X UI strings and just
plain looks better to the reader.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are building on Darwin (sometimes known as Mac OS X) and we
find the Mac OS X Tk.framework in the expected location we build
a proper Mac OS X application bundle with icons and info list. The
git-gui and git-citool commands are modified to be very short shell
scripts that just execute the application bundle, starting Tk with
our own info list and icon set.
Although the Makefile change here is rather large it makes for a
much more pleasant user experience on Mac OS X as git-gui now has
its own icon on the dock, in the standard tk_messageBox dialogs,
and the application name now says "Git Gui" instead of "Wish" in
locations such as the menu bar and the alt-tab window.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than displaying the stock red "Tk" icon in our window
title bars and on the task bar we now show a Git specific logo.
This is Henrik Nyh's logo that we also use in the startup wizard,
scaled to a 16x16 image for Windows task bar usage with a proper
transparent background.
Signed-off-by: Shawn O. Pearce <shawn.o.pearce@bankofamerica.com>
The setup wizard looks better if we layout the progress bar as
two lines: the first line holds the message text and our text
formatting of the progress while the second line holds the bar
itself. Both extend the full width of the window and we try to
pad out the message text so the window doesn't expand when the
completed progress number jumps to the next order of magnitude.
This change required updating the progress meter format string
to allow the application to supply the precision. So we also
are updating all of the translations at once to use the newer
formatting string.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Henrik came up with this alternative logo for gitweb and posted
it on his blog:
http://henrik.nyh.se/2007/06/alternative-git-logo-and-favicon
The msysGit port uses his logo within some of their components,
and frankly it looks better here in git-gui for our repository
setup wizard screen. The logo fits quite nicely along the left
edge of our window, leaving significantly more vertical space
for things like the git-fetch console output.
Because the logo changes the layout charateristics of the setup
window I also needed to adjust some of the padding for our widgets
and stop using a fixed width window size. We now let Tk compute
the correct size of the main window whenever the layout changes,
and drop the window into roughly the upper left 1/3 of the desktop
so its not quite centered but is likely to be far enough away from
any sort of task bars/menu bars/docks that the user may have along
any edge of the screen.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we have added a scrollbar to the console window because one
direction has too much text to fit in the available screen space
we should just keep the scrollbars. Its annoying to watch our
horizontal scrollbar bounce in and out of the window as additional
text is inserted into the widget and the need for the scrollbar
comes and goes.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the console finishes displaying its output and is "done" but
needs to draw a scrollbar to show the final output messages it
is possible for Tk to delete the window namespace before it does
the text widget updates, which means we are unable to add the
horizontal or vertical scrollbar to the window when the text
widget decides it cannot draw all glyphs on screen.
We need to delay deleting the window namespace until we know
the window is not going to ever be used again. This occurs if
we are done receiving output, the command is successful and the
window is closed, or if the window is open and the user chooses
to close the window after the command has completed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The program "msgfmt" was our only dependency on gettext. Since it
is more than just a hassle to compile gettext on MinGW, here is a
(very simple) drop-in replacement, which Works For Us.
[sp: Changed Makefile to enable/disable po2msg.sh by the new
NO_MSGFMT variable.]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the source repository is using an objects/info/alternates file
we need to copy the file to our new repository so that it can access
any objects that won't be copied/hardlinked as they are stored in the
alternate location.
We explicitly resolve all paths in the objects/info/alternates as
relative to the source repository but then convert them into an
absolute path for the new clone. This allows the new clone to
access the exact same locaton as the source repository, even if
relative paths had been used before.
Under Cygwin we assume that Git is Cygwin based and that the paths
in objects/info/alternates must be valid Cygwin UNIX paths, so we
need to run `cygpath --unix` on each line in the alternate list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are doing a "standard" clone by way of hardlinking the
objects (or copying them if hardlinks are not available) the
UI can freeze up for a good few seconds while Tcl scans all
of the object directories. This is espeically noticed on a
Windows system when you are working off network shares and
need to wait for both the NT overheads and the network.
We now show a progress bar as we count the objects and build
our list of things to copy. This keeps the user amused and
also makes sure we run the Tk event loop often enough that
the window can still be dragged around the desktop.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we failed to create our test hardlink for the first object
we need to link/copy then the only recourse we have is to make
a copy of the objects. Users don't really need to know the OS
details about why the hardlink failed as its usually because
they are crossing filesystem boundaries.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We shouldn't create scrollbars for the horziontal or vertical sides
unless there is enough content to make it worth drawing these widgets
on screen. This way users don't loose screen space to objects that
won't help them navigate the display.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are started outside of a git repository than it is likely
the user started us from some sort of desktop shortcut icon in
the operating system. In such a case the user is expecting us to
prompt them to locate the git repository they want to work on,
or to help them make a new repository, or to clone one from an
existing location. This is a very simple wizard that offers the
user one of these three choices.
When we clone a repository we always use the name `master` in the
local repository, even if the remote side does not appear to point
to that name. I chose this as a policy decision. Much of the Git
documentation talks about `master` being the default branch in a
repository and that's what git-init does too. If the remote side
doesn't call its default branch `master` most users just don't care,
they just want to use Git the way the documentation describes.
Rather than relying on the git-clone Porcelain that ships with
git we build the new repository ourselves and then obtain content
by git-fetch. This technique simplifies the entire clone process
to roughly: `git init && git fetch && git pull`. Today we use
three passes with git-fetch; the first pass gets us the bulk of
the objects and the branches, the second pass gets us the tags,
and the final pass gets us the current value of HEAD to initialize
the default branch.
If the source repository is on the local disk we try to use a
hardlink to connect the objects into the new clone as this can
be many times faster than copying the objects or packing them and
passing the data through a pipe to index-pack. Unlike git-clone
we stick to pure Tcl [file link -hard] operation thus avoiding the
need to fork a cpio process to setup the hardlinks. If hardlinks
do not appear to be supported (e.g. filesystem doesn't allow them or
we are crossing filesystem boundaries) we use file copying instead.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn O. Pearce <spearce@spearce.org>
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: Shawn 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: Shawn 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: Shawn 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: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Shawn 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: Shawn 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: Shawn O. Pearce <spearce@spearce.org>
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: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Simon 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: Shawn 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: Shawn 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: Harri Ilari Tapio Liusvaara <hliusvaa@cc.hut.fi>
Signed-off-by: Shawn 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: Harri Ilari Tapio Liusvaara <hliusvaa@cc.hut.fi>
Signed-off-by: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Shawn 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: Shawn 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: Shawn 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/441167
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn O. Pearce <spearce@spearce.org>
Dots in a UI string usually mean that a dialog box will
appear waiting for further input. So this patch removes
unneeded dots for actions that do not require user's
input.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I really prefer having a very short and sweet makefile output that
does not flood the user's screen with a ton of commands that they
don't care much about. Traditionally git-gui has hidden away the
actual commands from output by the $(QUIET*) series of macros but
allow them to be seen with either `make QUIET=` or `make V=1`.
This change makes our i18n message generation process to be a lot
shorter and easier to digest at a glance:
GITGUI_VERSION = 0.8.2.19.gb868-dirty
* new locations or Tcl/Tk interpreter
GEN git-gui
BUILTIN git-citool
INDEX lib/
MSGFMT po/de.msg 268 translated.
MSGFMT po/hu.msg 268 translated.
MSGFMT po/it.msg 268 translated.
MSGFMT po/ja.msg 268 translated.
MSGFMT po/ru.msg 249 translated, 12 fuzzy, 4 untranslated.
MSGFMT po/zh_cn.msg 60 translated, 37 fuzzy, 168 untranslated.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This particular message is talking about a specific option in the
configuration file named "gui.$name". This option is not localized
so we cannot localize the "gui." that denotes the section the option
$name is found within. Currently there are no plans to localize the
configuration options for git-gui, but if that were to change in the
future then it would be necessary to localize not only the "gui."
section prefix but also the $name (fontui and fontdiff).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We don't actually need to create the lib/msgs symlink back to our
po directory in the source tree. git-gui.sh is smart enough to
figure out this is where the msg files are and will load them from
the po directory if invoked as git-gui.sh.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
with contributions from LI Yang, WANG Cong, ZHANG Le, and rae l
from the zh-kernel.org mailing list.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This way, it should be easier for new translators to actually find out
about the glossary.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Usually, generated files are not part of the tracked content in
a project. However, translators may lack the tools to generate
git-gui.pot. Besides, it is possible that a contributor does
not even check out the repository, but gets this file via gitweb.
Pointed out by Junio.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This short note is to help a translation contributor to help us
localizing git-gui message files by covering the basics.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The procedure [mc ...] will translate the strings through msgcat.
Strings must be enclosed in quotes, not in braces, because otherwise
xgettext cannot extract them properly, although on the Tcl side both
delimiters would work fine.
[jes: I merged the later patches to that end.]
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tcl's msgcat library and corresponding mc procedure can locate a
translated string for any user message, provided that it is first
given a directory where the *.msg files are located containing the
translations.
During installation we will place the translations in lib/msgs/,
so we need to inform msgcat of this location once we determine it
during startup. Our source code tree however will store all of
the translations within the po/ directory, so we need to special
case this variant.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To support a localized version of git-gui we need to locate the
library directory early so we can initialize Tcl's msgcat package
to load translated messages from. This needs to occur before we
declare our git-version proc so that errors related to locating
git or assessing its version can be reported to the end-user in
their preferred language. However we have to keep the library
loading until after git-version has been declared, otherwise we
will fail to start git-gui if we are using a fake tclIndex that
was generated by our Makefile.
Signed-off-by: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn O. Pearce <spearce@spearce.org>
In a13ee29b97 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: Shawn 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: Shawn 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: Shawn 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: Väinö Järvelä <v@pp.inet.fi>
Signed-off-by: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn 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: Shawn O. Pearce <spearce@spearce.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
This is a essentially a copy of Paul Mackerras encoding support from
gitk. I stole the code from gitk commit fd8ccbec4f, as Paul has
already done all of the hard work setting up this translation table.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* 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
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>
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>
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>
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>
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>
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>
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>
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>
* 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
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>
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>
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>
Alex Riesen wanted a quieter installation process for git and its
contained git-gui. His earlier patch to do this failed to work
properly when V=1, and didn't really give a great indication of
what the installation was doing.
These rules are a little bit on the messy side, as each of our
install actions is composed of at least two variables, but in the
V=1 case the text is identical to what we had before, while in the
non-V=1 case we use some more complex rules to show the interesting
details, and hide the less interesting bits.
We now can also set QUIET= (nothing) to see the rules that are used
when V= (nothing), so we can debug those too if we have to. This is
actually a side-effect of how we insert the @ into the rules we use
for the "lists of things", like our builtins or our library files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The blame viewer is composed of two different areas, the file
area on top and the commit area on the bottom. If users are
trying to shift the focus it is probably because they want to
shift from one area to the other, so we just setup Tab and
Shift-Tab to jump from the one half to the other in a cycle.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Mark Levedahl <mlevedahl@gmail.com> noted that installation on Cygwin
to /usr/bin can cause problems with the automatic guessing of our
library location. The problem is that installation to /usr/bin
means we actually have:
/usr/bin = c:\cygwin\bin
/usr/share = c:\cygwin\usr\share
So git-gui guesses that its library should be found within the
c:\cygwin\share directory, as that is where it should be relative
to the script itself in c:\cygwin\bin.
In my first version of this patch I tried to use `cygpath` to resolve
/usr/bin and /usr/share to test that they were in the same relative
locations, but that didn't work out correctly as we were actually
testing /usr/share against itself, so it always was equal, and we
always used relative paths. So my original solution was quite wrong.
Mark suggested we just always disable relative behavior on Cygwin,
because of the complexity of the mount mapping problem, so that's
all I'm doing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because Tk does not assure us the order that it will process
children in before it destroys the main toplevel we cannot safely
save our geometry data during a "bind . <Destroy>" event binding.
The geometry may have already changed as a result of a one or
more children being removed from the layout. This was pointed
out in gitk by Mark Levedahl, and patched over there by commit
b6047c5a81.
So we now also use "wm protocol . WM_DELETE_WINDOW" to detect when
the window is closed by the user, and forward that close event to
our main do_quit routine.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently git-commit.sh (the command line commit user interface in
core Git) always gives precedence to the prior commit's message if
`commit --amend` is used and a $GIT_DIR/MERGE_MSG file also exists.
We actually were doing the same here in git-gui, but the amended
message got lost if $GIT_DIR/MERGE_MSG already existed because
we started a rescan immediately after loading the prior commit's
body into the edit buffer. When that happened the rescan found
MERGE_MSG existed and replaced the commit message buffer with the
contents of that file. This meant the user never saw us pick up
the commit message of the prior commit we are about to replace.
Johannes Sixt <J.Sixt@eudaptics.com> found this bug in git-gui by
running `git cherry-pick -n $someid` and then trying to amend the
prior commit in git-gui, thus combining the contents of $someid
with the contents of HEAD, and reusing the commit message of HEAD,
not $someid. With the recent changes to make cherry-pick use the
$GIT_DIR/MERGE_MSG file Johannes saw git-gui pick up the message
of $someid, not HEAD. Now we always use HEAD if we are amending.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Earlier git.git applied a large "war on whitespace" patch that was
created using 'apply --whitespace=strip'. Unfortunately a few of
git-gui's own files got caught in the mix and were also cleaned up.
That was a6080a0a44.
This patch is needed in git-gui.git to reapply those exact same
changes here, otherwise our version generator script is unable to
obtain our version number from git-describe when we are hosted in
the git.git repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint: (38 commits)
git-gui: Changed blame header bar background to match main window
git-gui: Favor the original annotations over the recent ones
git-gui: Improve our labeling of blame annotation types
git-gui: Use three colors for the blame viewer background
git-gui: Jump to original line in blame viewer
git-gui: Display both commits in our tooltips
git-gui: Run blame twice on the same file and display both outputs
git-gui: Display the "Loading annotation..." message in italic
git-gui: Rename fields in blame viewer to better descriptions
git-gui: Label the uncommitted blame history entry
git-gui: Switch internal blame structure to Tcl lists
git-gui: Cleanup redundant column management in blame viewer
git-gui: Better document our blame variables
git-gui: Remove unused commit_list from blame viewer
git-gui: Automatically expand the line number column as needed
git-gui: Make the line number column slightly wider in blame
git-gui: Use lighter colors in blame view
git-gui: Remove unnecessary space between columns in blame viewer
git-gui: Remove the loaded column from the blame viewer
git-gui: Clip the commit summaries in the blame history menu
...
The main window's diff header bar background switched from orange
to gold recently, and I liked the effect it had on readability of
the text. Since I wanted the blame viewer to match, here it is.
Though this probably should be a user defined color, or at least
a constant somewhere that everyone can reference.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Usually when you are looking at blame annotations for a region of
a file you are more interested in why something was originally
done then why it is here now. This is because most of the time
when we get original annotation data we are looking at a simple
refactoring performed to better organize code, not to change its
semantic meaning or function. Reorganizations are sometimes of
interest, but not usually.
We now show the original commit data first in the tooltip. This
actually looks quite nice as the original commit will usually have an
author date prior to the current (aka move/copy) annotation's commit,
so the two commits will now tend to appear in chronological order.
I also found myself to always be clicking on the line of interest
in the file column but I always wanted the original tracking data
and not the move/copy data. So I changed our default commit from
$asim_data (the simple move/copy annotation) to the more complex
$amov_data (the -M -C -C original annotation).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It feels wrong to call the -M -C -C annotations "move/copy tracking"
as they are actually the original locations. So I'm relabeling
the status bar to show "copy/move tracking annotations" for the
current file (no -M -C -C) as that set of annotations tells us who
put the hunk here (who moved/copied it). I'm now calling the -M
-C -C pass "original location annotations" as that's what we're
really digging for.
I also tried to clarify some of the text in the hover tooltip.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To prevent neighboring lines that are different commits from using
the same background color we now use 3 colors and assign them
by selecting the color that is not used before or after the line
in question. We still color "on the fly" as we receive hunks from
git-blame, but we delay our color decisions until we are getting
the original location data (the slower -M -C -C pass) as that is
usually more fine-grained than the current location data.
Credit goes to Martin Waitz for the tri-coloring concept.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the user clicks on a commit link within one of the columns
in the blame viewer we now jump them not just to that commit/file
pair but also to the line of the original file. This saves the
user a lot of time, as they don't need to search through the new
file data for the chunk they were previously looking at.
We also restore the prior view when the user clicks the back button
to return to a pior commit/file pair that they were looking at.
Turned out this was quite tricky to get working in Tk. Every time
I tried to jump the text widgets to the correct locations by way
of the "yview moveto" or "see" subcommands Tk performed the change
until the current event finished dispatching, and then reset the
views back to 0, making the change never take place. Forcing Tk
to run the pending events before we jump the UI resolves the issue.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we have commit data from both the simple blame and the
rename/move tracking blame and they differ than there is a
bigger story to tell. We now include data from both commits
so that the user can see that this link as moved, who moved
it, and where it originated from.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now perform two passes over any input file given to the blame
viewer. Our first pass is a quick "git-blame" with no options,
getting the details of how each line arrived into this file. We
are specifically ignoring/omitting the rename detection logic as
this first pass is to determine why things got into the state they
are in.
Once the first pass is complete and is displayed in the UI we run
a second pass, using the much more CPU intensive "-M -C -C" options
to perform extensive rename/movement detection. The output of this
second pass is shown in a different column, allowing the user to see
for any given line how it got to be, and if it came from somewhere
else, where that is.
This is actually very instructive when run on our own lib/branch.tcl
script. That file grew recently out of a very large block of code
in git-gui.sh. The first pass shows when I created that file, while
the second pass shows the original commit information.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user clicks on a line region that we haven't yet received
an annotation for from git-blame we show them "Loading annotation".
But I don't want the user to confuse this loading message with a
commit whose first line is "Loading annotation" and think we messed
up our display somehow. Since we never use italics for anything
else, I'm going with the idea that italic slant can be used to show
data is missing/elided out at the time being.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Calling the commit message pane $w_cmit is a tad confusing when
we also have the $w_cgrp column that shows the abbreviated SHA-1s.
So w_cmit -> w_cviewer, as it is the "commit viewer"; and
w_cgrp -> w_amov as it is the "annotated commit + move tracking"
column. Also changed line_data -> amov_data, as that list is
exactly the results shown in w_amov.
Why call the column "move tracking"? Because this column holds
data from "git blame -M -C". I'm considering adding an additional
column that holds the data from "git blame" without -M/-C, showing
who did the copy/move, and when they did it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user runs the blame viewer on a working directory file
instead of a specific commit-ish then we have no value for the
commit SHA1 or the summary line; this causes the history menu
to get an empty entry at the very bottom. We now look for this
odd case and call the meny entry "Working Directory".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Tcl list datatype is significantly faster to work with than
the array type, especially if our indexes are a consecutive set
of numbers, like say line numbers in a file.
This rather large change reorganizes the internal data structure
of the blame viewer to use a proper Tcl list for the annotation
information about a line. Each line is given its own list within
the larger line_data list, where the indexes correspond to various
facts about that particular line.
The interface does seem to be more responsive this way, with less
time required by Tcl to process blame, and to switch to another
version of the same file. It could just be a placebo effect, but
either way most Tcl experts perfer lists for this type of work over
arrays.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The code to handle our three different text widgets is a bit
on the messy side as we issue the same command on all three
widgets one at a time. Adding (or removing) columns from the
viewer is messy, as a lot of locations need to have the new
column added into the sequence, or removed from it.
We also now delete the tags we create for each commit when
we switch to display another "commit:path" pair. This way the
text viewer doesn't get bogged down with a massive number of tags
as we traverse through history.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The array variable "order" used to be used to tell us in what
order each commit was received in. Recent changes have removed
that need for an ordering and the "order" array is now just a
boolean 'do we have that commit yet' flag.
The colors were moved to fields, so they appear inside of the
blame viewer instance. This keeps two different concurrently
running blame viewers from stepping on each other's ordering
of the colors in group_colors.
Most of the other fields were moved around a little bit so
that they are organized by major category and value lifespan.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This list used to store the commits in the order we received
them in. I originally was using it to update the colors of
the commit before and the commit after the current commit,
but since that interface concept turned out to be horribly
ugly and has been removed we no longer need this list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
After we finish reading a chunk of data from the file stream
we know how many digits we need in the line number column to
show the current maximum line number. If our line number column
isn't wide enough, we should expand it out to the correct width.
Any file over our default allowance of 5 digits (99,999 lines)
is so large that the slight UI "glitch" when we widen the column
out is trivial compared to the time it will take Git to fully do
the annotations.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most source code files are under 9,999 lines of text, so using a
field width of 5 characters meant that we should have had one char
padding on the left edge (because we right-justify the line number).
Unfortunately when I added the right margin earlier (when I removed
the padding) I ate into the extra character's space, losing the left
margin. This put the line numbers too close to the commit column in
any file with more than 999 lines in it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The colors I originally picked out on a Mac OS X system look a
tad too dark on a Windows 2000 system; the greys are dark enough
to make it difficult to read some lines of text and the green used
to highlight the current commit was also difficult to read text on.
I also added a third grey to the mix, to try and help some files
that wind up with a number of neighboring chunks getting the same
colors.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Mac OS X the OS has "features" that like to draw thick black
borders around the text field that has focus. This is nice if
you want to know where your text is going and are blind as a bat,
but it isn't the best thing to have in a table that is being
faked through the abuse of Tk text widgets.
By setting our takefocus, highlightthickness and padx/y we can
get rid of this border and get our text widgets packed right next
to each other, with no padding between them. This makes the blame
background color smoothly run across the entire line of commit data,
line number and file content.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Originally I had placed this loaded column between the line number
and the file line data to help users know if a particular line has
received annotation data or not yet. This way users would know if
the line(s) they were interested in were ready for viewing, or if
they still had to wait. It also was an entertaining way for the
user to spend their time waiting for git-blame --incremental to
compute the complete set of annotations.
However it is completely useless now that we show the abbreviated
commit SHA-1 and author initials in the leftmost column. That area
is empty until we get the annotation data, and as soon as we get it
in we display something there, indicating to the user that there is
now blame data ready. Further with the tooltips the user is likely
to see the data as soon as it comes in, as they are probably not
keeping their mouse perfectly still. So I'm removing the field to
save screen space for more useful things, like file content.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some commit lines can get really long when users enter a lot of
text without linewrapping (for example). Rather than letting the
menu get out of control in terms of width we clip the summary to
the first 50+ characters.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently Tk on Mac OS X won't draw a button with an image using a
transparent background. Instead it draws the button using some sort
of 3D effect, even though I asked for no relief and no border. The
background is also not our orange that we expected it to be.
Earlier I had tried this same trick on Windows and it draws the same
way as the button did, so I'm going to switch to the label as that
seems to be more portable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we have two commits right next to each other in the final
file and they were kept as different blocks in the leftmost
column then its probably because the original filename was
different. To help the user know where they are digging into
when they click on that link we now show the original file in
the tooltip, but to save space we do so only if the original
file is not the same as the file we are currently viewing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Consecutive chunks of a file could come from the same commit, but
have different original file names. Previously we would have put
them into a single group, but then the hyperlink would jump to only
one of the files, and the other would not be accessible. Now we can
get to the other file too.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
gitweb has long had a feature where the user can click on any
commit the blame display and go visit that commit's information
page. From the user could go get the blame display for the file
they are tracking, and try to digg through the history of any
part of the code they are interested in seeing.
We now offer somewhat similiar functionality in git-gui. The 4
digit commit abreviation in the first column of our blame view is
now offered as a hyperlink if the commit isn't the one we are now
viewing the blame output for (as there is no point in linking back
to yourself). Clicking on that link will stop the current blame
engine (if still running), push the new target commit onto the
history stack, and restart the blame viewer at that commit, using
the "original file name" as supplied by git-blame for that chunk
of the output.
Users can navigate back to a version they had been viewing before
by way of a back button, which offers the prior commits in a popup
menu displayed right below the back button. I'm always showing the
menu here as the cost of switching between views is very high; you
don't want to jump to a commit you are not interested in looking at
again.
During switches we throw away all data except the cached commit data,
as that is relatively small compared to most source files and their
annotation marks. Unfortunately throwing this per-file data away in
Tcl seems to take some time; I probably should move the line indexed
arrays to proper lists and use [lindex] rather than the array lookup
(usually lists are faster).
We now start the git-blame process using "nice", so that its priority
will drop hopefully below our own. If I don't do this the blame engine
gets a lot of CPU under Windows 2000 and the git-gui user interface is
almost non-responsive, even though Tcl is just sitting there waiting
for events.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Computing the blame records for a large file with a long project
history can take git a while to run; traditionally we have shown
a little meter in the status area of our blame viewer that lets
the user know how many lines have been finished, and how far we
are through the process.
Usually such progress indicators are drawn with a little progress
bar in the window, where the bar shows how much has been completed
and hides itself when the process is complete. I'm using a very
simple hack to do that: draw a canvas with a filled rectangle.
Of course the time remaining has absolutely no relationship to the
progress meter. It could take very little time for git-blame to get
the first 90% of the file, and then it could take many times that to
get the remaining 10%. So the progress meter doesn't really have any
sort of assurances that it relates to the true progress of the work.
But in practice on some ugly history it does seem to hold a reasonable
indicator to the completion status. Besides, its amusing to watch and
that keeps the user from realizing git is being somewhat slow.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
At one point I tried to present the blame viewer to an audience of
people on a 640 by 480 pixel LCD projector. This did not work at
all as the top area (the file data) was taking up all of the screen
realestate and the split point was not adjustable by the user. In
general locking the user into a specific ratio of display is just
not user friendly.
So we now place a split pane control into the middle of our blame
window, so the user can adjust it to their current needs. If the
window increases (or decreases) in height we assign the difference
to the file data area, as that is generally the area of the window
that users are trying to see more of when they grow the window.
Unfortunately there appears to be a bug in the "pack" layout manager
in Tcl/Tk 8.4.1. The status bar and the lower commit pane was being
squashed if the window decreased in height. I think the pack manager
was just not decreasing the size of the panedwindow slave properly if
the main window shrank. Switching to the "grid" layout manager fixes
the problem, but is slightly uglier setup code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Frequently when I'm looking at blocks of code in the blame
viewer I want to know who is the culprit, or who I should
be praising for a job well done. The tooltips nicely show
this if I mouse over a block, but it doesn't work to get
this detail at a glance.
Since we don't use the leftmost commit column for anything
after the first line within a commit group I'm now tossing
the author's initials into that field, right justified. It
is quite clearly not a SHA-1 number as we always show the
SHA-1 in lowercase, while we explicitly select only the
uppercase characters from an author's name field, and only
those that are following whitespace.
I'm using initials here over anything else as they are quite
commonly unique within small development teams. The leading
part of the email address field was out for some of the teams
I work with, as there the email addresses are all of the form
"Givenname.Surname@initech.com". That will never fit into the
4 characters available.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The | in the continued lines of the same commit group as not
easily seen on the left edge; putting a single space in front
of the pipe makes it slightly more visually appealing to me as
I can follow the line down through the group to the next commit
marker.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we no longer redraw colors every time we select a particular
commit there is no need to redraw the screen after we get a new commit
in from blame --incremental.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The selected commit's blame header is now drawn in green, using
the same background color that is shown in the main file content
viewer. The result is a much better looking commit pane, as we
use bold for header "keys" and proportional width fonts for the
stuff that doesn't need to be fixed width to maintain its formatting.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the mouse is over a particular line and we have blame data
for that line, but its not the active commit, we should show the
user information about that commit like who the author was and
what the subject (first line) was.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we don't allow the user to select text from the file
viewer right now I'm disabling the normal text cursor and
putting in a plain arror instead. This way users don't
think they can select and copy text, because they can't.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If two consecutive lines in the final file came from the same commit
then we store a "|" in the first column rather than the commit id,
for the second and subsequent lines in that block. This cleans up
the interface so runs associated with the same commit can be more
easily seen visually.
We also now use the abbreviation "work" for the uncommitted stuff in
your working directory, rather than "0000". This looks nicer to the
eyes and explains pretty quickly what is going on.
There was also a minor bug in the commit abbreviation column for the
last line of the file. This is now also fixed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The git-gui blame viewer has always been ugly as s**t. Linus Torvalds
suggested the coloring scheme I'm using here, which is two different
shades of grey for the background colors, and black text on a pale green
background for the currently selected/focused commit.
The difference is a massive improvement. The interface no longer will
cause seizures in people who are prone to that sort of thing. It no
longer uses a very offensive hot pink. The green being current actually
makes sense. And not having the background of the other non-current
lines change when you change the current commit is really a big deal.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The blame viewer has this silly blank line at the bottom of it;
we really don't want to see it displayed as we will never get
any blame data for that line (it doesn't exist in the source).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A lot of this code was pre-class, which meant that I just sort of
copied and pasted my way through it, rather than being really smart
and using a variable for each widget's path name. Since we have a
field for each path, we can use those throughout the constructor
and make things a lot neater.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now show the first 4 digits of each commit in the left most
column of our blame viewer, before the line numbers. These are
drawn as the data becomes available from git-blame --incremental,
and helps the user to visually group lines together.
I'm using only the first 4 digits because within a given cluster
of lines its unlikely that two neighboring commits will have the
same 4 digit prefix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The default font was already bold, so marking the selected file with bold
font did not work. Change that to lightgray background.
Also, the header colors are now softer, giving better readability.
Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
Revert "Make the installation target of git-gui a little less chatty"
git-gui: Verify Tcl/Tk is new enough for our needs
git-gui: Attach font_ui to all spinbox widgets
This reverts commit c289f6fa1f.
Junio pointed out that Alex's change breaks in some cases, like
when V=1, and is more verbose than it should be even if that worked.
I'm backing it out and redoing it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
For quite a while we have been assuming the user is running on
a Tcl/Tk 8.4 or later platform. This may not be the case on
some very old systems. Unfortunately I am pretty far down the
path of using the Tcl/Tk 8.4 commands and options and cannot
easily work around them to support earlier versions of Tcl/Tk.
So we'll check that we are using the correct version up front,
and if not we'll stop with a related error message.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Earlier I missed making sure our spinbox widgets used the same font
as the other widgets around them. This meant that using a main font
with a size of 20 would make every widget in the options dialog huge,
but the spinboxes would be left with whatever the OS native font is.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Its wrong to exit the application if we destroy a random widget
contained withing something else; especially if its some small
trivial thing that has no impact on the overall operation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To improve performance on fork+exec impoverished systems (such as
Windows) we want to avoid running git-symbolic-ref on every rescan
if we can do so. A quick way to implement such an avoidance is to
just read the HEAD ref ourselves; we'll either see it as a symref
(starts with "ref: ") or we'll see it as a detached head (40 hex
digits). In either case we can treat that as our current branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt pointed out that dropping to 0 lines of context
does allow the user to get more fine-grained hunk selection,
especially since we don't currently support "highlight and
apply (or revert)".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user has no branches at all (their refs/heads/ is empty)
and they are on a detached HEAD we have a valid repository but
there are no branches to populate into the branch pulldown in
the create branch dialog. Instead of erroring out we can skip
that part of the dialog, much like we do with tracking branches
or tags when the user doesn't have any.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Recently git-merge learned to avoid generating the diffstat after
a merge by reading the merge.diffstat configuration option. By
default this option is assumed to be true, as that is the old
behavior. However we can force it to false by setting it as a
standard boolean option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Git has supported remote branch deletion for quite some time, but
I've just never gotten around to supporting it in git-gui. Some
workflows have users push short-term branches to some remote Git
repository, then delete them a few days/weeks later when that topic
has been fully merged into the main trunk. Typically in that style
of workflow the user will want to remove the branches they created.
We now offer a "Delete..." option in the Push menu, right below the
generic "Push..." option. When the user opens our generic delete
dialog they can select a preconfigured remote, or enter a random
URL. We run `git ls-remote $url` to obtain the list of branches and
tags known there, and offer this list in a listbox for the user to
select one or more from.
Like our local branch delete dialog we offer the user a way to filter
their selected branch list down to only those branches that have been
merged into another branch. This is a very common operation as the
user will likely want to select a range of topic branches, but only
delete them if they have been merged into some sort of common trunk.
Unfortunately our remote merge base detection is not nearly as strict
as the local branch version. We only offer remote heads as the test
commit (not any local ones) and we require that all necessary commits
to successfully run git-merge-base are available locally. If one or
more is missing we suggest that the user run a fetch first.
Since the Git remote protocol doesn't let us specify what the tested
commit was when we evaluated our decision to execute the remote delete
there is a race condition here. The user could do a merge test against
the trunk, determine a topic branch was fully merged, but before they
can start pushing the delete request another user could fast-forward
the remote topic branch to a new commit that is not merged into the
trunk. The delete will arrive after, and remove the topic, even though
it was not fully merged.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Git's native command line interface has had branch renaming
support for quite a while, through the -m/-M options to the
git-branch command line tool. This is an extremely useful
feature as users may decide that the name of their current
branch is not an adequate description, or was just entered
incorrectly when it was created.
Even though most people would consider git-branch to be a
Porcelain tool I'm using it here in git-gui as it is the
only code that implements the rather complex set of logic
needed to successfully rename a branch in Git. Currently
that is along the lines of:
*) Backup the ref
*) Backup the reflog
*) Delete the old ref
*) Create the new ref
*) Move the backed up reflog to the new ref
*) Record the rename event in the reflog
*) If the current branch was renamed, update HEAD
*) If HEAD changed, record the rename event in the HEAD reflog
*) Rename the [branch "$name"] section in the config file
Since that is some rather ugly set of functionality to implement
and get right, and some of it isn't easily accessible through the
raw plumbing layer I'm just cheating by relying on the Porcelain.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Windows and Mac OS X platforms do not generally use the tearoff
menu feature found on traditional X11 based systems. On Windows the
Tk engine does support the feature, but it really is out of place and
just confuses people who aren't used to working on a UNIX system. On
Mac OS X its not supported for the root menu bar and its submenus, as
it doesn't fit into the overall platform UI model.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we cannot locate our git-gui library directory, or we find it
but the tclIndex file is not present there (or it is present but
is not something we are allowed to read) the user cannot use the
application. Rather than silently ignoring the errors related to
the tclIndex file being unavailable we report them up front and
display to the user why we cannot start.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we are using our "non-optimized" tclIndex format (which is
just a list of filenames, in the order necessary for source'ing)
we are doing all of our loading before we even tested to see if
GITGUI_VERBOSE was set in the environment. This meant we never
showed the files as we sourced them into the environment.
Now we setup our overloaded auto_load and source scripts before
we attempt to define our library path, or source the scripts that
it mentions. This way GITGUI_VERBOSE is always honored if set.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we now try to automatically guess the library directory
in certain installations users may wonder where git-gui is getting
its supporting files from. We now display this location in our
About dialog, and we also include the location we are getting our
Git executables from.
Unfortunately users cannot use this 'About git-gui' dialog to
troubleshoot library loading problems; the dialog is defined by
code that exists in the library directory, creating a catch-22.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In some workflows it is common for a large number of temporary
branches to be created in a remote repository, get fetched to
clients that typically only use git-gui, and then later have
those branches deleted from the remote repository once they have
been fully merged into all destination branches. Users of git-gui
would obviously like to have their local tracking branches cleaned
up for them, otherwise their local tracking branch namespace would
grow out of control.
The best known way to remove these tracking branches is to run
"git remote prune <remotename>". Even though it is more of a
Porcelain command than plumbing I'm invoking it through the UI,
because frankly I don't see a reason to reimplement its ls-remote
output filtering and config file parsing.
A new configuration option (gui.pruneduringfetch) can be used to
automatically enable running "git remote prune <remotename>" after
the fetch of that remote also completes successfully. This is off
by default as it require an additional network connection and is
not very fast on Cygwin if a large number of tracking branches have
been removed (due to the 2 fork+exec calls per branch).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt asked me to try to avoid embedding the runtime location
of git-gui's library directory in the executable script. Not embedding
it helps the MinGW to be relocatable to another directory should a user
wish to install the programs in a directory other than the location the
packager wanted them to be installed into.
Most of this is a hack. We try to determine if the path of our master
git-gui script will be able to locate the lib by ../share/git-gui/lib.
This should be true if $(gitexecdir) and $(libdir) have the same prefix.
If they do then we defer the assignment of $(libdir) until runtime, and
we get it from $argv0 rather than embedding it into the script itself.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Alberto Bertogli reported on #git that git-gui was exiting with
alt-q, while gitk on the same system was exiting with ctrl-q.
That was not what I wanted. I really wanted M1B to be bound to
the Control key on most non-Mac OS X platforms, but according to
Sam Vilain M1 on most systems means alt. Since gitk always does
control, I'm doing the same thing for all non-Mac OS X systems.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our GITGUI_LIBDIR macro was testing only for @@ at the start of
the path, assuming nobody would ever find that to be a reasonable
prefix for a directory to install our library into. That is most
likely a valid assumption, but its even more unlikely they would
have the start be @@GITGUI_ and the end be @@. Note that we
cannot use the full string here because that would get expanded
by the sed replacement in our Makefile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Petr Baudis pointed out the main git.git repository's Makefile dies
now if git-gui 0.7.0-rc1 or later is being used and TCL_PATH was not
set to a working tclsh program path. This breaks people who may have
a working build configuration today and suddenly upgrade to the latest
git release.
The tclIndex is required for git-gui to load its associated lib files,
but using the Tcl auto_load procedure to source only the files we need
is a performance optimization. We can emulate the auto_load by just
source'ing every file in that directory, assuming we source class.tcl
first to initialize our crude class system.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a simple change to match what gitk does when it shows
a commit; we format using ISO dates (yyyy-mm-dd HH:MM:SS).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We can use [list ...] rather than "", especially when we are talking
about values as then they are properly escaped if necessary. Small
nit, but probably not a huge deal as the only data being inlined here
is Tk paths.
Some of the lines in the parser code were longer than 80 characters
wide, and they actually were all the same value on the end part of
the line. Rather than keeping the mess copied-and-pasted around we
can set the last argument into a local variable and reuse it many
times.
The commit display code was also rather difficult to read on an 80
character wide terminal, so I'm moving it all into a double quoted
string that is easier to read.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user doesn't give us a revision parameter to our blame
subcommand then we can generate blame against the working tree
file by passing the file path off to blame with the --contents
argument. In this case we cannot obtain the contents of the
file from the ODB; instead we must obtain the contents by
reading the working directory file as-is.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The browser subcommand now optionally accepts a single revision
argument; if no revision argument is supplied then we use the
current branch as the tree to browse. This is very common, so
its a nice option.
Our blame subcommand now tries to perform the same assumptions
as the command line git-blame; both the revision and the file
are optional. We assume the argument is a filename if the file
exists in the working directory, otherwise we assume the argument
is a revision name. A -- can be supplied between the two to force
parsing, or before the filename to force it to be a filename.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I think it was Andy Parkins who pointed out that git gui blame HEAD f
does not work if f is in a subdirectory and we are currently running
git-gui within that subdirectory. This is happening because we did
not take the user's prefix into account when we computed the file
path in the repository.
We now assume the prefix as returned by rev-parse --show-prefix is
valid and we use that during the command line blame subcommand when
we apply the parameters.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our blame viewer code has historically been a mess simply
because the data for multiple viewers was all crammed into
a single pair of Tcl arrays. This made the code hard to
read and even harder to maintain.
Now that we have a slightly better way of tracking the data
for our "meta-widgets" we can make use of it here in the
blame viewer to cleanup the code and make it easier to work
with long term.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a variable reference to a field is to an array, and it is
the only reference to that field in that method we cannot make
it an inlined [set foo] call as the regexp was converting the
Tcl code wrong. We were producing "[set foo](x)" for "$foo(x)",
and that isn't valid Tcl when foo is an array. So we just punt
if the only occurance has a ( after it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that we have a slightly easier method of working with per-widget
data we should make use of that technique in our browser and console
meta-widgets, as both have a decent amount of information that they
store on a per-widget basis and our current approach of handling
it is difficult to follow.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As most of the git-gui interface is based upon "meta-widgets"
that need to carry around a good deal of state (e.g. console
windows, browser windows, blame viewer) we have a good deal
of messy code that tries to store this meta-widget state in
global arrays, where keys into the array are formed from a
union of a unique "object instance id" and the field name.
This is a simple class system for Tcl that allows us to
hide much of that mess by making Tcl do what it does best;
process strings to manipulate its own code during startup.
Each object instance is placed into its own namespace. The
namespace is created when the object instance is created and
the namespace is destroyed when the object instance is removed
from the system. Within that namespace we place variables for
each field within the class; these variables can themselves be
scalar values or full-blown Tcl arrays.
A simple class might be defined as:
class map {
field data
field size 0
constructor {} {
return $this
}
method set {name value} {
set data($name) $value
incr size
}
method size {} {
return $size
} ifdeleted { return 0 }
}
All fields must be declared before any constructors or methods. This
allows our class to generate a list of the fields so it can properly
alter the definition of the constructor and method bodies prior to
passing them off to Tcl for definition with proc. A field may optionally
be given a default/initial value. This can only be done for non-array
type fields.
Constructors are given full access to all fields of the class, so they
can initialize the data values. The default values of fields (if any)
are set before the constructor runs, and the implicit local variable
$this is initialized to the instance identifier.
Methods are given access to fields they actually use in their body.
Every method has an implicit "this" argument inserted as its first
parameter; callers of methods must be sure they supply this value.
Some basic optimization tricks are performed (but not much). We
try to only upvar (locally bind) fields that are accessed within a
method, but we err on the side of caution and may upvar more than
we need to. If a variable is accessed only once within a method
and that access is by $foo (read) we avoid the upvar and instead
use [set foo] to obtain the value. This is slightly faster as Tcl
does not need to lookup the variable twice.
We also offer some small syntatic sugar for interacting with Tk and
the fileevent callback system in Tcl. If a field (say "foo") is used
as "@foo" we insert instead the true global variable name of that
variable into the body of the constructor or method. This allows easy
binding to Tk textvariable options, e.g.:
label $w.title -textvariable @title
Proper namespace callbacks can also be setup with the special cb proc
that is defined in each namespace. [cb _foo a] will invoke the method
_foo in the current namespace, passing it $this as the first (implied)
parameter and a as the second parameter. This makes it very simple to
connect an object instance to a -command option for a Tk widget or to
a fileevent readable or writable for a file channel.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I found it useful to be able to use j/k (vi-like keys) to move
up and down the list of branches to merge and shift-j/k to do
the selection, much as shift-up/down (arrow keys) would alter
the selection.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
All menu entries talk about "staging" and "unstaging" changes, but the
titles of the file lists use different wording, which may confuse
newcomers.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we support vi-like keys for scrolling in other UI contexts
we can easily do so here too. Tk's handy little `event generate'
makes this a lot easier than I thought it would be. We may want
to go back and fix some of the other vi-like bindings to redirect
to the arrow and pageup/pagedown keys, rather than running the
view changes directly.
I've bound 'v' to visualize, as this is a somewhat common thing
to want to do in the merge dialog. Control (or Command) Return
is also bound to start the merge, much as it is bound in the
main window to activate the commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When merging branches using our local merge feature it can be
handy to know the first few digits of the commit the ref points
at as well as the short description of the branch name.
Unfortunately I'm unable to use three listboxes in a row, as Tcl
freaks out and refuses to let me have a selection in more than
one of them at any given point in time. So instead we use a
fixed width font in the existing listbox and organize the data
into three columns. Not nearly as nice looking, but users can
continue to use the listbox's features.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt pointed out that git-gui was randomly selecting
which branch (or tag!) it will show in the merge dialog when
more than one ref points at the same commit. This can be a
problem for the user if they want to merge a branch, but the
ref that git-gui selected to display was actually a tag that
points at the commit at the tip of that branch. Since the
user is looking for the branch, and not the tag, its confusing
to not find it, and worse, merging the tag causes git-merge to
generate a different message than if the branch was selected.
While I am in here and am messing around I have changed the
for-each-ref usage to take advantage of its --tcl formatting,
and to fetch the subject line of the commit (or tag) we are
looking at. This way we could present the subject line in the
UI to the user, given them an even better chance to select
the correct branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like the console procs I have moved the code related to merge
support into their own namespace, so that they are isolated
from the rest of the world.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users who are used to vi and recent versions of gitk may want
to scroll the diff region using vi style keybindings. Since
these aren't bound to anything else and that widget does not
accept focus for data input, we can easily support that too.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To help modularize git-gui better I'm isolating the code and
variables required to handle our little console windows into
their own namespace. This way we can say console::new rather
than new_console, and the hidden internal procs to create the
window and read data from our filehandle are off in their own
private little land, where most users don't see them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm finding it difficult to work with a 6,000+ line Tcl script
and not go insane while looking for a particular block of code.
Since most of the program is organized into different units of
functionality and not all users will need all units immediately
on startup we can improve things by splitting procs out into
multiple files and let auto_load handle things for us.
This should help not only to better organize the source, but
it may also improve startup times for some users as the Tcl
parser does not need to read as much script before it can show
the UI. In many cases the user can avoid reading at least half
of git-gui now.
Unfortunately we now need a library directory in our runtime
location. This is currently assumed to be $(sharedir)/git-gui/lib
and its expected that the Makefile invoker will setup some sort of
reasonable sharedir value for us, or let us assume its going to be
$(gitexecdir)/../share.
We now also require a tclsh (in TCL_PATH) to just run the Makefile,
as we use tclsh to generate the tclIndex for our lib directory. I'm
hoping this is not an unncessary burden on end-users who are building
from source.
I haven't really made any functionality changes here, this is just a
huge migration of code from one file to many smaller files. All of
the new changes are to setup the library path and install the library
files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like core-Git we now track the values that we embed into our shell
script wrapper, and we "recompile" that wrapper if they are changed.
This concept was lifted from git.git's Makefile, where a similar
thing was done by Eygene Ryabinkin. Too bad it wasn't just done
here in git-gui from the beginning, as the git.git Makefile support
for GIT-GUI-VARS was really just because git-gui doesn't do it on
its own.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Whenever we want to execute a git subcommand from the plumbing
layer (and on rare occasion, the more porcelain-ish layer) we
tend to use our proc wrapper, just to make the code slightly
cleaner at the call sites. I wasn't doing that in a couple of
places, so this is a simple cleanup to correct that.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than passing "-font font_ui" to every widget that we
create we can instead reconfigure the option database for
all widget classes to use our font_ui as the default widget
font. This way Tk will automatically setup their defaults
for us, and we can reduce the size of the application.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
An earlier change tossed these optionMenu font configurations
all over the code, when really we can just rename the proc to
a hidden internal name and provide our own wrapper to install
the font configuration we really want.
We also don't need to set these option database entries in all
of the procedures that open dialogs; instead we should just set
one time, them after we have the font configuration ready for use.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since Tk automatically wraps lines for us in tk_messageBox
widgets we don't need to try to wrap them ourselves. Its
actually worse that we linewrapped this here in the script,
as not all fonts will render this dialog nicely.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A coworker who was new to git-gui recently tried to make an octopus
merge when he did not quite mean to. Unfortunately in his case the
branches had file level conflicts and failed to merge with the octopus
strategy, and he didn't quite know why this happened. Since most users
really don't want to perform an octopus merge this additional safety
valve in front of the merge process is a good thing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that the command line git-commit has made displaying
the subject (first line) of the newly created commit popular
we can easily do the same thing here in git-gui, without the
ugly part of forking off a child process to obtain that first
line.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the path of our wish executable that are running under
contains spaces we need to make sure they are escaped in
a proper Tcl list, otherwise we are unable to start gitk.
Reported by Randal L. Schwartz on #git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Uwe Kleine-König discovered git-gui mangled his surname and did
not send the proper UTF-8 byte sequence to git-commit-tree when
his name appeared in the commit message (e.g. Signed-Off-By line).
Turns out this was related to other trouble that I had in the past
with trying to use "fconfigure $fd -encoding $enc" to select the
stream encoding and let Tcl's IO engine do all of the encoding work
for us. Other parts of git-gui were just always setting the file
channels to "-encoding binary" and then performing the encoding
work themselves using "encoding convertfrom" and "convertto", as
that was the only way I could make UTF-8 filenames work properly.
I found this same bug in the amend code path, and in the blame
display. So its fixed in all three locations (commit creation,
reloading message for amend, viewing message in blame).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Mimick what we do for gitk. Since you do have a source file,
git-gui.sh, which is separate from the target, it should be much
easier in git-gui's Makefile.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This reverts commit e2a1bc67d3.
Junio rightly pointed out this patch doesn't handle the
`make install` target very well:
Junio C Hamano <junkio@cox.net> writes:
> You should never generate new files in the source tree from
> 'install' target. Otherwise, the usual pattern of "make" as
> yourself and then "make install" as root would not work from a
> "root-to-nobody-squashing" NFS mounted source tree to local
> filesystem. You should know better than accepting such a patch.
By showing the basename of the directory very early in the
title bar I can more easily locate a particular git-gui
session when I have 8 open at once and my Windows taskbar
is overflowing with items.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* er/ui:
Always bind the return key to the default button
Do not break git-gui messages into multiple lines.
Improve look-and-feel of the git-gui tool.
Teach git-gui to use the user-defined UI font everywhere.
Allow wish interpreter to be defined with TCLTK_PATH
If we generate a blame status string before we have obtained
any annotation data at all from the input file, or if the input
file is empty, our total_lines will be 0. This causes a division
by 0 error when we blindly divide by the 0 to compute the total
percentage of lines loaded. Instead we should report 0% done.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a dialog/window has a default button registered not every
platform associates the return key with that button, but all
users do. We have to register the binding of the return key
ourselves to make sure the user's expectations of pressing
return will activate the default button are met.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Many git-gui messages were broken into a multiple lines to make
good paragraph width. Unfortunately in reality it breaks the paragraph
width completely, because the dialog window width does not coincide
with the paragraph width created by the current font.
Tcl/Tk's standard dialog boxes are breaking the long lines
automatically, so it is better to make long lines and let the
interpreter do the job.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Made the default buttons on the dialog active and focused upon the
dialog appearence.
Bound 'Escape' and 'Return' keys to the dialog dismissal where it
was appropriate: mainly for dialogs with only one button and no
editable fields, but on console output dialogs as well.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some parts of git-gui were not respecting the default GUI font.
Most of them were catched and fixed.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Makefile got one external option:
- TCLTK_PATH: the path to the Tcl/Tk interpreter.
Users (or build wrappers) may set this variable to the
location of the wish executable.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-04-04 11:37:55 -04:00
989 changed files with 47410 additions and 178936 deletions
git-mktree - Build a tree-object from ls-tree formatted text
SYNOPSIS
--------
'git-mktree' [-z]
DESCRIPTION
-----------
Reads standard input in non-recursive `ls-tree` output format,
and creates a tree object. The object name of the tree object
built is written to the standard output.
OPTIONS
-------
-z::
Read the NUL-terminated `ls-tree -z` output instead.
Author
------
Written by Junio C Hamano <junkio@cox.net>
Documentation
--------------
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
