tokkee.org

git-gui: Fix the blame viewer destroy handler.

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>

git-gui: Add a search command to the blame viewer.

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>

git-gui: Fix the blame window shape.

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>

git-gui: Fix switch statement in lib/merge.tcl

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>

git-gui: Fix fetching from remotes when adding them

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: Fix removing non-pushable remotes

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>

git-gui: Make input boxes in init/clone/open dialogs consistent

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>

git-gui: Avoid using the term URL when specifying repositories

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>

git-gui: gui.autoexplore makes explorer to pop up automatically after picking

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>

git-gui: Add Explore Working Copy to the Repository menu

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>

git-gui: Use git web--browser for web browsing

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>

git-gui: mkdir -p when initializing new remote repository

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>

git-gui: Add support for removing remotes

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>

git-gui: Add support for adding remotes

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>

git-gui: Squash populate_{push,fetch}_menu to populate_remotes_menu

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>

git-gui: Clarify the Remote -> Delete... action

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>

git-gui: Remove space from the end of aspell's reply before processing

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>

git-gui: Make Ctrl-T safe to use for conflicting files.

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>

git-gui: Do not automatically stage file after merge tool finishes

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>

git-gui: Show/hide "Sign Off" based on nocommitmsg option

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>

Merge branch 'maint'

git-gui: Help identify aspell version on Windows too

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>

git-gui: Reenable staging unmerged files by clicking the icon.

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 2fe5b2ee42897a3acc78e5ddaace3775eb2713ca
(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>

git-gui: Support the encoding menu in gui blame.

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>

git-gui: Optimize encoding name resolution using a lookup table.

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>

git-gui: Allow forcing display encoding for diffs using a submenu.

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>

git-gui: Add a menu of available encodings.

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>

git-gui: Cleanup handling of the default encoding.

- 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>

git-gui: Assume `blame --incremental` output is in UTF-8

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>

git-gui: Use gitattribute "encoding" for file content display

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>

git-gui: Add support for calling out to the prepare-commit-msg hook

Signed-off-by: Joshua Williams <joshua.williams@qlogic.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Hide commit related UI during citool --nocommit

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>

git-gui: Add more integration options to citool.

- 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>

git-gui: Updated German translation.

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

git-gui: I18n fix sentence parts into full sentences for translation again.

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>

git-gui: Restore ability to Stage Working Copy for conflicts.

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>

git-gui: Fix Blame Parent & Context for working copy lines.

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>

Merge branch 'maint'

* maint:
  git-gui: Fix diff parsing for lines starting with "--" or "++"

git-gui: Fix diff parsing for lines starting with "--" or "++"

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>

git-gui: Show special diffs for complex conflict cases.

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>

git-gui: Make F5 reselect a diff, if an untracked file is selected.

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>

git-gui: Reimplement and enhance auto-selection of diffs.

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>

git-gui: Support conflict states _U & UT.

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>

git-gui: Support more merge tools.

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>

git-gui: Don't allow staging files with conflicts.

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>

git-gui: Support calling merge tools.

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>

git-gui: Support resolving conflicts via the diff context menu.

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>

git-gui: Mark forgotten strings for translation.

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

Merge branch 'maint'

* maint:
  git-gui: Fix string escaping in po2msg.sh
  git gui: show diffs with a minimum of 1 context line

Conflicts:
lib/option.tcl

git-gui: Fix string escaping in po2msg.sh

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>

git gui: show diffs with a minimum of 1 context line

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>

git-gui: Allow specifying an initial line for git gui blame.

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>

git-gui: Better positioning in Blame Parent Commit

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>

git-gui: Support passing blame to a parent commit.

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>

git-gui: Support starting gitk from Gui Blame

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>

git-gui: Teach git gui about file type changes

Signed-off-by: Gustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: update all remaining translations to French.

Simply..

Signed-off-by: Alexandre Bourget <alexandre.bourget@savoirfairelinux.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Update french translation

Signed-off-by: Alexandre Bourget <alexandre.bourget@savoirfairelinux.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui 0.11

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

git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'

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>

git-gui: add a part about format strings in po/README

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>

git-gui: update po/it.po

Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: update Japanese translation

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: Update swedish translation.

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

git-gui: Update git-gui.pot for 0.11 nearing release

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

git-gui: Update German translation

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

git-gui (Windows): Change wrapper to execdir 'libexec/git-core'

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>

git-gui (Windows): Switch to relative discovery of oguilib

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>

git-gui: Correct installation of library to be $prefix/share

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>

git-gui: Fix gitk search in $PATH to work on Windows

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>

git-gui: Preserve scroll position on reshow_diff.

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>

git-gui: Fix the Remote menu separator.

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>

git-gui: "Stage Line": Treat independent changes in adjacent lines better

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>

git-gui: Fix "Stage/Unstage Line" with one line of context.

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>

git-gui: Correct 'Visualize Branches' on Mac OS X to start gitk

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>

git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core

Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Add a menu item to invoke full copy detection in blame.

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>

Kill the blame back-end on window close.

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>

Add options to control the search for copies in blame.

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>

Fix pre-commit hooks under MinGW/MSYS

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>

git-gui: MERGE_RR lives in .git/ directly with newer Git versions

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>

git-gui: Exit shortcut in MacOSX repaired

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>

git-gui: Implement "Stage/Unstage Line"

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>

git-gui: Don't select the wrong file if the last listed file is staged.

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>

git-gui: Fix accidental staged state toggle when clicking top pixel row

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>

git-gui: Move on to the next filename after staging/unstaging a change

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>

git-gui: Vertically align textboxes with labels

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>

git-gui: Handle workdir detection when CYGWIN=nowinsymlinks

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>

git-gui: Add a --trace command line option

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>

git-gui: Delete branches with 'git branch -D' to clear config

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>

git-gui: Setup branch.remote,merge for shorthand git-pull

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>

git-gui: Update German translation

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

Merge branch 'maint'

* maint:
  git-gui: Don't use '$$cr master' with aspell earlier than 0.60

git-gui: Don't use '$$cr master' with aspell earlier than 0.60

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>

git-gui: Report less precise object estimates for database compression

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>

git-gui: use +/- instead of ]/[ to show more/less context in diff

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>

git-gui: Update french translation

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

git-gui: Switch keybindings for [ and ] to bracketleft and bracketright

Thanks to Michele Ballabio for the quick fix.
This resolves the error introduced by c91ee2bd61.

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

git-gui 0.10

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

git-gui: Add shortcut keys for Show More/Less Context

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>