Take advantage of the new log-edit feature that allows to show a diff
with C-c C-d while editing the log message.
Signed-off-by: NAlexandre Julliard <julliard@winehq.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Without explicit version deps in the rpm spec file, 'yum update git'
effectively does nothing. Require explicit versions of the subpackages,
so that they get pulled in on an update.
Signed-off-by: NJames Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The current code can access memory outside of the tree buffer in the
case of malformed tree entries.

This patch prevents this by:

 * The rest of the buffer must be at least 24 bytes (at least 1 byte
   mode, 1 blank, at least one byte path name, 1 NUL, 20 bytes sha1).

 * Check that the last NUL (21 bytes before the end) is present.
   This ensures that strlen() and get_mode() calls stay within the
   buffer.

 * The mode may not be empty. We have only to reject a blank at the
   begin, as the rest is handled by if (c < '0' || c > '7').

 * The blank is ensured by get_mode().

 * The path must contain at least one character.
Signed-off-by: NMartin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There are two possible confusions with the color.interactive
description:

  1. the short name "interactive" implies that it covers all
     interactive commands; let's explicitly make it so, even
     though there are no other interactive commands which
     currently use it

  2. Not all parts of "git add --interactive" are controlled
     by color.interactive (specifically, the diffs require
     tweaking color.diff). So let's clarify that it applies
     only to displays and prompts.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Users with color.diff set to true/auto will not see color in
"git add -i" unless they also set color.interactive.

This changes the semantics of color.interactive to control only the
coloring of the interaction aspect of the command and let color.diff
to control the color of hunk picker, which would arguably be more
convenient.

Old $use_color variable is now renamed to $menu_use_color to make it
clear that it is about coloring the interaction.

The "colored" subroutine now checks if the passed color is defined,
instead of checking $use_color variable, to decide if the lines should
be colored.  The various variables that define colors for different
parts of the output are set or unset depending on the setting of
color.interactive and color.diff configuration variables.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When color support was added, we colored the diffs ourselves.
However, 4af756f3 changed this to simply run "git diff-files"
twice, keeping the colored output separately.

This makes the internal diff color variables obsolete with
one exception: when splitting hunks, we have to manually
recreate the fragment for each part of the split. Thus we
keep $fraginfo_color around to do that correctly.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The current tag parsing code can access memory outside the tag buffer,
if \n are missing. This patch prevent this behaviour.
Signed-off-by: NMartin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock
Asciidoc configuration:

@@ -149,7 +153,10 @@
 # Inline macros.
 # Backslash prefix required for escape processing.
 # (?s) re flag for line spanning.
-(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
+# Explicit so they can be nested.
+(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
 # Anchor: [[[id]]]. Bibliographic anchor.
 (?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3
 # Anchor: [[id,xreflabel]]

This default regex now matches explicit values, and unfortunately in this
case gitlink was being matched by just 'link', causing the wrong inline
macro template to be applied. By renaming the macro, we can avoid being
matched by the wrong regex.
Signed-off-by: NDan McGee <dpmcgee@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

They should be spelled with a single colon.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When e-mail address is empty (e.g. "A U Thor <>"), --pretty=format
misparsed the commit header and did not pick up the date field correctly.

Noticed by Marco, fixed slightly differently with additional sanity
check and with a test.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMark Levedahl <mdl123@verizon.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

'git-filter-branch branch' could fail producing the error:
"Which ref do you want to rewrite?" if existed another branch
or tag, which name was 'branch-something' or 'something/branch'.

[jc: original report and fix were done between Dmitry Potapov
and Dscho; I rewrote it using "rev-parse --symbolic-full-name"]
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The plumbing level can understand that the user meant
"refs/heads/master" when the user says "master" or
"heads/master", but there is no easy way for the scripts to
figure it out without duplicating the dwim_ref() logic.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Because it is so tempting to expect "git stash clear stash@{4}"
to remove the fourth element in the stash while leaving other
elements intact, we should not blindly throw away everything
upon seeing such a command.

This may change when we start using "git reflog delete" to
selectively nuke a single (or multiple, for that matter) stash
entries with such a command line.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some scripts and libraries check stderr to detect a failing command,
instead of checking the exit code.  Because the output from git-status
is not primarily for machine consumption, it would not hurt to send
these messages to stdout instead and it will make it easier to drive
the command for such callers.
Signed-off-by: NMarco Costalba <mcostalba@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

With "too many unreachable loose objects" git gc --auto will always
trigger. This clutters the output of git am and thus git rebase.
Signed-off-by: NMichael Stefaniuc <mstefani@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It is a good practice to write program output to a temporary file
during the test, as it would allow easier postmortem when the tested
program does break.  But there is no benefit in writing the expected
output out to the temporary.

This actually fixes a bug in check_verify_failure() routine.
The intention of the test seems to make sure the "git mktag" command
fails, and it spits out the expected error message.  But if the
command did not fail as expected, the shell function as originally
written would not have detected the failure.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There is nothing _wrong_ with egrep per se, but this way we
would have less dependency on external tools.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

As pointed out by Junio, it's unnecessary to use "grep -E" and ".+" when we can
just use "grep" and "..*".
Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Using \+ to mean "one or more" in grep without -E is a GNU
extension outside POSIX.  Avoid it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* git://repo.or.cz/git-gui:
  git-gui: Make commit log messages end with a newline
  Added Swedish translation.
  git-gui: Unconditionally use absolute paths with Cygwin
  git-gui: Handle file mode changes (644->755) in diff viewer
  git-gui: Move frequently used commands to the top of the context menu.

Signed-off by: Marco Costalba <mcostalba@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There is no point to this. Either:

  1. The program has already loaded git_diff_ui_config, in
     which case this is a noop.
  2. The program didn't, which means it is plumbing that
     does not _want_ git_diff_ui_config to be loaded.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The funcname patterns influence the "comment" on @@ lines of
the diff. They are safe to use with plumbing since they
don't fundamentally change the meaning of the diff in any
way.

Since all diff users call either diff_ui_config or
diff_basic_config, we can get rid of the lazy reading of the
config.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The diff porcelain uses git_diff_ui_config to set
porcelain-ish config options, like automatically turning on
color. The plumbing specifically avoids calling this
function, since it doesn't want things like automatic color
or rename detection.

However, some diff options should be set for both plumbing
and porcelain. For example, one can still turn on color in
git-diff-files using the --color command line option. This
means we want the color config from color.diff.* (so that
once color is on, we use the user's preferred scheme), but
_not_ the color.diff variable.

We split the diff config into "ui" and "basic", where
"basic" is suitable for use by plumbing (so _most_ things
affecting the output should still go into the "ui" part).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMartin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

A NUL byte at beginning of file, or just after a newline
would provoke an invalid buf[-1] access in a few places.

* builtin-grep.c (cmd_grep): Don't access buf[-1].
* builtin-pack-objects.c (get_object_list): Likewise.
* builtin-rev-list.c (read_revisions_from_stdin): Likewise.
* bundle.c (read_bundle_header): Likewise.
* server-info.c (read_pack_info_file): Likewise.
* transport.c (insert_packed_refs): Likewise.
Signed-off-by: NJim Meyering <meyering@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The rewrite changed the output to use the path relative to the
top of the work tree without a good reason.  This fixes it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJim Meyering <meyering@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Now the routine is an open-coded loop that avoids an extra
strlen() in the previous implementation, it got a bit too big to
be inlined.  Uninlining it makes code footprint smaller but the
result still retains the avoidance of strlen() cost.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This updates send-pack and fast-import to use symbolic constants
for checking the return values from check_ref_format(), and also
futureproof the logic in lock_any_ref_for_update() to explicitly
name the case that is usually considered an error but is Ok for
this particular use.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

commit 3157dd9e (git-svn: unlink
internal index files after operations) introduced unlinking
index files after fetching.  However, this missed indices for
refs that were created by globbing branches and tags.  This will
track all refs we ever touch during a fetch and unlink them at
exit time.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMartin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Certain codepaths (notably "git log --pretty=format...") use
prefixcmp() extensively, with very short prefixes.  In those cases,
calling strlen() is a wasteful operation, so avoid it.

Initial patch by Marco Costalba.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Recent check_ref_format() returns -3 as well as -1 (general
error) and -2 (less than two levels).  The caller was explicitly
checking for -1, to allow "HEAD" but still needed to disallow
bogus refs.

This introduces symbolic constants for the return values from
check_ref_format() to make them read better and more
meaningful.  Normal ref creation codepath can still treat
non-zero return values as errors.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It makes no sense since there is no working tree. A soft
reset should be fine, though.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The config parsing routines use the static global
'config_file' to store the FILE* pointing to the current
config file being parsed. The function get_next_char()
automatically converts an EOF on this file to a newline for
the convenience of its callers, and it sets config_file to
NULL to indicate that EOF was reached.

This throws away useful information, though, since some
routines want to call ftell on 'config_file' to find out
exactly _where_ the routine ended. In the case of a key
ending at EOF boundary, we ended up segfaulting in some
cases (changing that key or adding another key in its
section), or failing to provide the necessary newline
(adding a new section).

This patch adds a new flag to indicate EOF and uses that
instead of setting config_file to NULL. It also makes sure
to add newlines where necessary for truncated input. All
three included tests fail without the patch.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>