Don't set the needs-refresh flag when inserting a new file info, since
ewoc refreshes it upon insert already; this makes a full refresh twice
as fast.
Also make git-fileinfo-prettyprint a little faster by not retrieving
permission values twice.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of just setting the state to up-to-date, retrieve the full
state again, so that the file type can be displayed properly.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Skip non-zero stage files during git-ls-files -c, they are handled
later. Also fix git-insert-info-list to merge duplicate file names.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running "git apply --check" while --whitespace=fix is
enabled (either from the command line or via the configuration),
we reported that "N line(s) applied after _fixing_", but --check
by itself does not apply and this message was alarming.
We could even reword the message to say "N line(s) would have
been applied after fixing...", but this patch does not go that
far. Instead, we just make it use the "N lines add whitespace
errors" warning, which happens to be a good diagnostic message a
user would expect from the --check option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I've heard of several users puzzled by this, and it sometimes it
appears as if git-svn is doing nothing on slower connections and
larger repositories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SVN requires that paths be URI-escaped for HTTP(S) repositories.
file:// and svn:// repositories do not need these rules.
Additionally, accessing individual paths inside repositories
(check_path() and get_log() do NOT require escapes to function
and in fact it breaks things).
Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We truncate hunk-header line at 80 bytes, but that 80th byte
could be in the middle of a character, which is bad. This uses
pick_one_utf8_char() function to make sure we do not cut a character
in the middle.
This assumes that the internal representation of the text is
UTF-8. This needs to be extended in the future but the optimal
direction has not been decided yet.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original interface assumed that the input string is
always terminated with a NUL, but that wasn't too useful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
utf8_width() function was doing two different things. To pick a
valid character from UTF-8 stream, and compute the display width of
that character. This splits the former to a separate function
pick_one_utf8_char().
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Handle the T status from git-diff-index to display type changes
between file/symlink/subproject. Also always show the file type for
symlink and subprojects to indicate that they are not normal files.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows displaying correctly the executable flag for the initial
commit, and will make it possible to show the file type for up-to-date
symlinks and subprojects.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio 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: James Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: Junio 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: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio 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: Jeff King <peff@peff.net>
Signed-off-by: Junio 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: Jeff King <peff@peff.net>
Signed-off-by: Junio 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: Jeff King <peff@peff.net>
Signed-off-by: Junio 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: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio 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: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio 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: Junio 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: Junio 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: Junio 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: Junio 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: Marco Costalba <mcostalba@gmail.com>
Signed-off-by: Junio 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: Michael Stefaniuc <mstefani@redhat.com>
Signed-off-by: Junio 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: Junio 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: Junio 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: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio 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.
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: Jeff King <peff@peff.net>
Signed-off-by: Junio 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: Jeff King <peff@peff.net>
Signed-off-by: Junio 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: Jeff King <peff@peff.net>
Signed-off-by: Junio 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: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio 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: Junio 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: Junio C Hamano <gitster@pobox.com>
Alexandre Julliard