git-gui: Improve font rendering on retina macbooks

Signed-off-by: Mads Dørup <mads@dorup.dk>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: added gui.maxrecentrepo to extend the number of remembered repos

The list of recently opened repositories shown when launching git-gui from
outside a repository was hard coded to only show a maximum of 10 items.
This config variable allows the user to override this default.

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: show the maxrecentrepo config option in the preferences dialog

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: Add gui.displayuntracked option

When git is used to track only a subset of a directory, or
there is no sure way to divide files to ignore from files to track,
git user have to live with large number of untracked files. These files
present in file list, and should always be scrolled through
to handle real changes. Situation can become even worse, then number
of the untracked files grows above the maxfilesdisplayed limit. In the
case, even staged can be hidden by git-gui.

This change introduces new configuration variable gui.displayuntracked,
which, when set to false, instructs git-gui not to show untracked files
in files list. They can be staged from commandline or other tools (like
IDE of file manager), then they become visible. Default value of the
option is true, which is compatible with current behavior.

Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: right half window is paned

For long descriptions it would be nice to be able to resize
the comment text field.

Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: corrected setup of git worktree under cygwin.

Under cygwin the _gitworktree variable needs to contain the Windows
style path string so the output provided by git rev-parse must
be converted from cygwin path style to native.

Reviewed-by: Jesse Welch <jesse.welch@baml.com>
Signed-off-by: John Patrick Murphy <john.murphy@baml.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
git-gui: add menu item to launch a bash shell on Windows.

When using git-gui as the primary git application on Windows it can be
awkward obtaining a suitable shell. This commit adds a menu item to the
Repository menu that launches the bash shell provided with the git
installation on Windows.

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
sha1write: make buffer const-correct

We are passed a "void *" and write it out without ever
touching it; let's indicate that by using "const".

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitk: Tag display improvements

When a commit has many tags, the tag icons in the graph display can
easily become so wide as to push the commit message off the right-hand
edge of the graph display pane.  This changes the display so that if
there are more than 3 tags or they would take up more than a quarter
of the width of the pane, we instead display a single tag icon with
a legend inside it like "4 tags...".  If the user clicks on the tag
icon, gitk then displays all the tags in the diff display pane.

Signed-off-by: Paul Mackerras <paulus@samba.org>
git-gui: correct spelling errors in comments

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
gitk: Support -G option from the command line

The -G option's usage is exactly analogous to that of -S, so
supporting it is easy.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Refactor per-line part of getblobdiffline and its support

For later use with data sources other than a pipe, refactor the big
worker part of getblobdiffline to a separate function
parseblobdiffline.  Also refactor its initialization and wrap-up to
separate routines.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Split out diff part in $commitinfo

So far we just parsed everything after the headers into the "comment"
bit of $commitinfo, including notes and -- if you gave weird options
-- the diff.

Split out the diff, if any, into a separate field.  It's easy to
recognize, since it always starts with /^diff/ and is preceded by an
empty line.

We take care to snip away said empty line.  The display code already
properly spaces the end of the message from the first diff, and
leaving another empty line at the end looks ugly.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Support showing the gathered inline diffs

The previous commit split the diffs into a separate field.  Now we
actually want to show them.

To that end we use the stored diff, and

- process it once to build a fake "tree diff", i.e., a list of all
  changed files;

- feed it through parseblobdiffline to actually format it into the
  $ctext field, like the existing diff machinery would.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Recognize -L option

This gives line-log support to gitk, by exploiting the new support for
processing and showing "inline" diffs straight from the git-log
output.

Note that we 'set allknown 0', which is a bit counterintuitive since
this is a "known" option.  But that flag prevents gitk from thinking
it can optimize the view by running rev-list to see the topology; in
the -L case that doesn't work.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Paul Mackerras <paulus@samba.org>
pack-objects: name pack files after trailer hash

Our current scheme for naming packfiles is to calculate the
sha1 hash of the sorted list of objects contained in the
packfile. This gives us a unique name, so we are reasonably
sure that two packs with the same name will contain the same
objects.

It does not, however, tell us that two such packs have the
exact same bytes. This makes things awkward if we repack the
same set of objects. Due to run-to-run variations, the bytes
may not be identical (e.g., changed zlib or git versions,
different source object reuse due to new packs in the
repository, or even different deltas due to races during a
multi-threaded delta search).

In theory, this could be helpful to a program that cares
that the packfile contains a certain set of objects, but
does not care about the particular representation. In
practice, no part of git makes use of that, and in many
cases it is potentially harmful. For example, if a dumb http
client fetches the .idx file, it must be sure to get the
exact .pack that matches it. Similarly, a partial transfer
of a .pack file cannot be safely resumed, as the actual
bytes may have changed.  This could also affect a local
client which opened the .idx and .pack files, closes the
.pack file (due to memory or file descriptor limits), and
then re-opens a changed packfile.

In all of these cases, git can detect the problem, as we
have the sha1 of the bytes themselves in the pack trailer
(which we verify on transfer), and the .idx file references
the trailer from the matching packfile. But it would be
simpler and more efficient to actually get the correct
bytes, rather than noticing the problem and having to
restart the operation.

This patch simply uses the pack trailer sha1 as the pack
name. It should be similarly unique, but covers the exact
representation of the objects. Other parts of git should not
care, as the pack name is returned by pack-objects and is
essentially opaque.

One test needs to be updated, because it actually corrupts a
pack and expects that re-packing the corrupted bytes will
use the same name. It won't anymore, but we can easily just
use the name that pack-objects hands back.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
clone,fetch: catch non positive --depth option value

Instead of simply ignoring the value passed to --depth option when
it is zero or negative, catch and report it as an error to let
people know that they were using the option incorrectly.

Original-patch-by: Andrés G. Aragoneses <knocte@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
glossary-content.txt: rephrase magic signature part

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support pathspec magic :(exclude) and its short form :!

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pathspec.c: support adding prefix magic to a pathspec with mnemonic magic

Back in 233c3e6 (parse_pathspec: preserve prefix length via
PATHSPEC_PREFIX_ORIGIN - 2013-07-14), parse_pathspec() is taught to
save prefix length as a dynamic magic. This is needed when the
pathspec is passed to another process and and prefix lenght would be
lost.

Back then we support two cases. If the pathspec is normal, e.g. "abc",
we simply add the prefix to become ":(prefix:2)abc". If the pathspec
contains long magic, e.g. ":(foo,bar)abc" then we turn it to
":(foo,bar,prefix:2)abc". We do not support prefixing on short form,
because the only supported mnemonic '/' disappears after the the
preprocessing steps.

With the introduction of exclude magic with mnemonic '!', we need to
add support for the short form case so that ':!abc' becomes
':(exclude,prefix:2)abc'. Without this, it will break

    cd Documentation
    git add -p -- . ':!technical'

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>