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>
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>
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>
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>
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>
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>
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>
Allow dynamically changing the encoding from the blame
viewer as well.
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>
- 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>
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>
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>
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>
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>
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>
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>
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>
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>
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 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>
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>
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>
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>
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>
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>
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>
