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>

Simply..
Signed-off-by: NAlexandre Bourget <alexandre.bourget@savoirfairelinux.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

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

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>

This should help tranlators that need to reorder words and strings.
Original explanation by Christian Stimming.

Also remove unneeded backslashes.
Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

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

This updates Japanese translation to match the updated git-gui.pot.
Signed-off-by: Nしらいしななこ <nanako3@lavabit.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

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

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

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

git-gui needs bindir in PATH to be able to run 'git'.  bindir
however is not necessarily in PATH if started directly through a
Windows shortcut.  Therefore, we used to add the directory
git-gui is located in.  But with the new 'libexec/git-core'
layout this directory is no longer identical to bindir.

This commit modifies the wrapper script to discover the bindir
and add it to PATH.
Signed-off-by: NSteffen Prohaska <prohaska@zib.de>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Instead of using an absolute path, git-gui can discover its
gui library using a relative path from execdir.  We want to
use the relative path discovery on MinGW to avoid issues
with translation of absolute paths.
Signed-off-by: NSteffen Prohaska <prohaska@zib.de>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

We always wanted the library for git-gui to install into the
$prefix/share directory, not $prefix/libexec/share.  All of
the files in our library are platform independent and may
be reused across systems, like any other content stored in
the share directory.

Our computation of where our library should install to was broken
when git itself started installing to $prefix/libexec/git-core,
which was one level down from where we expected it to be.
Signed-off-by: NSteffen Prohaska <prohaska@zib.de>
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 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: NAlexander Gavrilov <angavrilov@gmail.com>
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>

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: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NShawn 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: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

In Git 1.6 and later gitk is in $prefix/bin while git-gui and all
of the other commands are in $gitexecdir, which is typically not
the same as $prefix/bin.  So we cannot launch $gitexecdir/gitk and
expect it to actually start gitk properly.

By allowing git-gui to locate the script via $PATH and then using
exactly that path when we source it during the application start
we can correctly run gitk on any Git 1.5 or later.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NAbhijit Menon-Sen <ams@toroid.org>
Signed-off-by: NShawn 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: NAlexander Gavrilov <angavrilov@gmail.com>
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 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: NJohannes Schindelin <johannes.schindelin@gmx.de>
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>

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

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

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

* maint:
  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: NShawn 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: NJohannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>