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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn 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 2fe5b2ee
(Restore ability to Stage Working Copy for conflicts)
Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com>
Tested-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Tested-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Tested-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NShawn 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: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NJoshua Williams <joshua.williams@qlogic.com>
Signed-off-by: NShawn 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: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

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 617ceee6 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: NAlexander Gavrilov <angavrilov@gmail.com>
Tested-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn O. Pearce <sop@google.com>

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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn 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: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NGustaf Hendeby <hendeby@isy.liu.se>
Signed-off-by: NShawn 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: NSteffen Prohaska <prohaska@zib.de>
Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Back in 15430be5 ("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: NShawn O. Pearce <spearce@spearce.org>

It was positioned incorrectly (offset by one position)
if the menu had a tear-off handle.
Signed-off-by: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NAbhijit Menon-Sen <ams@toroid.org>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: NShawn 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: NSoeren Finster <sf@9by6.de>
Signed-off-by: NShawn 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: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NShawn 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: NAbhijit Menon-Sen <ams@toroid.org>
Tested-by: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NShawn 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: NRichard Quirk <richard.quirk@gmail.com>
Signed-off-by: NShawn 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: NAbhijit Menon-Sen <ams@toroid.org>
Signed-off-by: NShawn 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: NShawn 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: NShawn 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: NShawn 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: NMichele Ballabio <barra_cuda@katamail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Thanks to Michele Ballabio for the quick fix.
This resolves the error introduced by c91ee2bd.
Signed-off-by: NShawn 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: NJonathan del Strother <jon.delStrother@bestbefore.tv>
Signed-off-by: NShawn 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: NShawn O. Pearce <spearce@spearce.org>