Some ancient platforms do not have an extensive list of alternate names for
character encodings. For example, Solaris 7 and IRIX 6.5 do not know that
ISO-8859-1 is the same as ISO8859-1. Modern platforms do know this, so use
the older name.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even if the user explicitly gave her own message to "git merge", the
command still added its standard merge message. It resulted in a
useless repetition like this:
% git merge -m "Merge early part of side branch" `git rev-parse side~2`
% git show -s
commit 37217141e7519629353738d5e4e677a15096206f
Merge: e68e646 a1d2374
Author: しらいし ななこ <nanako3@lavabit.com>
Date: Wed Dec 2 14:33:20 2009 +0900
Merge early part of side branch
Merge commit 'a1d2374f8f52f4e8a53171601a920b538a6cec23'
The gave her own message because she didn't want git to add the
standard message (if she wanted to, she wouldn't have given one,
or she would have prepared it using git-fmt-merge-msg command).
Noticed by Nanako Shiraishi
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The patch structure has def_name component that is used to validate the
sanity of a "diff --git" patch by checking pathnames that appear on the
patch header lines for consistency. The git_header_name() function is
used to compute this out of "diff --git a/... b/..." line, but the code
always stripped one level of prefix (i.e. "a/" and "b/"), without paying
attention to -p<n> option. Code in find_name() function that parses other
lines in the patch header (e.g. "--- a/..." and "+++ b/..." lines) however
did strip the correct number of leading paths prefixes, and the sanity
check between these computed values failed.
Teach git_header_name() to honor -p<n> option like find_name() function
does.
Found and reported by Steven J. Murdoch who also wrote tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't take the author name information without re-encoding from the raw
commit object buffer.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we are rebasing we know that the header lines in the
patch are good and that we don't need to pick up any headers
from the body of the patch.
This makes it possible to rebase commits whose commit message
start with "From" or "Date".
Test vectors by Jeff King.
Signed-off-by: Lukas Sandström <luksan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The t/t9700/test.pl script uses method invocation syntax when
using the Cwd module to determine the current working directory.
This fails on cygwin, since cygwin perl specifically checks for
any arguments to the cwd() function and croak()'s with the message
"Usage: Cwd::cwd()". (In perl v5.8.8 distribution, see the file
perl-5.8.8/cygwin/cygwin.c lines 139-157)
In order to avoid the problem, we replace the method invocation
syntax with a simple function call.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some test scripts run Perl scripts as if they were git-* scripts, and
thus need to use the same perl that will be put in the shebang line of
git*.perl commands. $PERL_PATH therefore needs to be used instead of
a bare "perl".
The tests can fail if another perl is found in $PATH before the one
defined in $PERL_PATH.
Example test failure caused by this: the perl defined in $PERL_PATH has
Error.pm installed, and therefore the Git.pm's Makefile.PL doesn't install
the private copy. The perl from $PATH doesn't have Error.pm installed, and
all git*.perl scripts invoked during the test will fail loading Error.pm.
Makefile patch by Jeff King <peff@peff.net>.
Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git grep" currently an error when you combine the -F and -i flags.
This isn't in line with how GNU grep handles it.
This patch allows the simultaneous use of those flags.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Brian Collins <bricollins@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Once upon a time, format-patch would use its default stat
plus patch format only when no diff format was given on the
command line. This meant that "format-patch -p" would
suppress the stat and show just the patch.
Commit 68daa64 changed this to keep the stat format when we
had an "implicit" patch format, like "-U5". As a side
effect, this meant that an explicit patch format was now
ignored (because cmd_format_patch didn't know the reason
that the format was set way down in diff_opt_parse).
This patch unbreaks what 68daa64 did (while still preserving
what 68daa64 was trying to do), reinstating "-p" to suppress
the default behavior. We do this by parsing "-p" ourselves
in format-patch, and noting whether it was used explicitly.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit b5227d8 changed the behavior of "ls-files" with
respect to includes, but accidentally broke the "-i" option
The original behavior was:
1. if no "-i" is given, cull all results according to --exclude*
2. if "-i" is given, show the inverse of (1)
The broken behavior was:
1. if no "-i" is given:
a. for "-o", cull results according to --exclude*
b. for index files, always show all
2. if "-i" is given:
a. for "-o", shows the inverse of (1a)
b. for index files, always show all
The fixed behavior keeps the new (1b) behavior introduced
by b5227d8, but fixes the (2b) behavior to show only ignored
files, not all files.
This patch also tweaks the documentation. The original text
was somewhat obscure in the first place, but it is also now
inaccurate (the relationship between (1b) and (2b) is not
quite a "reverse").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Colored word diff without context lines firstly printed all the hunk
headers among each other and then printed the diff.
This was due to the code relying on getting at least one context line at
the end of each hunk, where the colored words would be flushed (it is
done that way to be able to ignore rewrapped lines).
Noticed by Markus Heidelberg.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Usually we show deletion as a big hunk deleting all of the
file's text. However, for files with no content, the diff
shows just the 'deleted file mode ...' line. This patch
cause "add -p" (and related commands) to recognize that line
and explicitly ask about deleting the file.
We only add the "stage this deletion" hunk for empty files,
since other files will already ask about the big content
deletion hunk. We could also change those files to simply
display "stage this deletion", but showing the actual
deleted content is probably what an interactive user wants.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
GIT_DIFFTOOL_PROMPT doesn't have any effect if overridden with --prompt.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes a regression introduce by d68dc34 (git-describe: Die early if
there are no possible descriptions, 2009-08-06).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This enables gitk to show the patch text with correct glyphs if the locale
is not UTF-8.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This mbox file must have been added by accident in e9fe804 (git-mailinfo:
Fix getting the subject from the in-body [PATCH] line, 2008-07-14).
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git grep" would segfault if its -f option was used because it would
try to use an uninitialized strbuf, so initialize the strbuf.
Thanks to Johannes Sixt <j.sixt@viscovery.net> for the help with the
test cases.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some types of corruption to a pack may confuse the deflate stream
which stores an object. In Andy's reported case a 36 byte region
of the pack was overwritten, leading to what appeared to be a valid
deflate stream that was trying to produce a result larger than our
allocated output buffer could accept.
Z_BUF_ERROR is returned from inflate() if either the input buffer
needs more input bytes, or the output buffer has run out of space.
Previously we only considered the former case, as it meant we needed
to move the stream's input buffer to the next window in the pack.
We now abort the loop if inflate() returns Z_BUF_ERROR without
consuming the entire input buffer it was given, or has filled
the entire output buffer but has not yet returned Z_STREAM_END.
Either state is a clear indicator that this loop is not working
as expected, and should not continue.
This problem cannot occur with loose objects as we open the entire
loose object as a single buffer and treat Z_BUF_ERROR as an error.
Reported-by: Andy Isaacson <adi@hexapodia.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In all parts of git, .gitignore and other exclude files
impact only how we treat untracked files; they should have
no effect on files listed in the index.
This behavior was originally implemented very early on in
9ff768e, but only for --exclude-from. Later, commit 63d285c
accidentally caused us to trigger the behavior for
--exclude-per-directory.
This patch totally ignores excludes for files found in the
index. This means we are reversing the original intent of
9ff768e, while at the same time fixing the accidental
behavior of 63d285c. This is a good thing, though, as the
way that 9ff768e behaved does not really make sense with the
way exclusions are used in modern git.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make "git add -p" to not skip files that are in index even if they are
excluded (by .gitignore etc.). This fixes the contradictory behavior
that "git status" and "git commit -a" listed such files as modified, but
"git add -p FILENAME" ignored them.
Signed-off-by: Pauli Virtanen <pav@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some MTAs reject Cc: lines longer than 78 chars.
Avoid this by using the same join as "To:" ",\n\t"
so each subsequent Cc entry is on a new line.
RCPT TO: should have a single entry per line.
see: http://www.ietf.org/rfc/rfc2821.txt
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With --prefix=string that does not end with a slash, the top-level entries
are written out with the specified prefix as expected, but no paths in the
directories are added.
Fix this by adding the prefix in write_archive_entry() instead of letting
get_pathspec() and read_tree_recursive() pair; they are designed to only
handle prefixes that are path components.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running "git show-branch" without any parameter in a repository that
has showbranch.default defined, we used to rely on the fact that our
handcrafted option parsing loop never looked at av[0].
The array of default strings had the first real command line argument in
default_arg[0], but the option parser wanted to look at the array starting
at av[1], so we assigned the address of -1th element to av to force the
loop start working from default_arg[0].
This no longer worked since 5734365 (show-branch: migrate to parse-options
API, 2009-05-21), as parse_options_start() saved the incoming &av[0] in
its ctx->out and later in parse_options_end() it did memmove to ctx->out
(with ctx->cpidx == 0), overwriting the memory before default_arg[] array.
I am not sure if this is a bug in parse_options(), or a bug in the caller,
and tonight I do not have enough concentration to figure out which. In
any case, this patch works the issue around.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes '--relative-date' so that it does not give '0
year, 12 months', for the interval 360 <= diff < 365.
Signed-off-by: Johan Sageryd <j416@1616.se>
Signed-off-by: Jeff King <peff@peff.net>
parse_long_opt always matches both --opt and --no-opt for any option
"opt", and only get_value checks whether --no-opt is actually valid.
Since the options for git branch contains both "no-merged" and "merged"
there are two matches for --no-merge, but no exact match. With this
patch the negation of a NONEG option is rejected earlier, but it changes
the error message from "option `no-opt' isn't available" to "unknown
option `no-opt'".
[jk: added test]
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The earlier logic tried to colour any and all blank lines that were added
beyond the last blank line in the original, but this was very wrong. If
you added 96 blank lines, a non-blank line, and then 3 blank lines at the
end, only the last 3 lines should trigger the error, not the earlier 96
blank lines.
We need to also make sure that the lines are after the last non-blank line
in the postimage as well before deciding to paint them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test the effect of an earlier change by f7835a2 (preserve mtime of local
clone, 2009-09-12) to keep stale loose object files stale in the new
repository when a local clone is made by copying files in .git/
directory.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, the call to authors-prog was not properly escaped, so any
special characters in the Subversion username, such as spaces and
semi-colons, would be interpreted by the shell rather than being passed
in as the first argument. Now all unsafe characters are escaped using
"git rev-parse --sq-quote"
[ew: switched from "\Q..\E" to "rev-parse --sq-quote"]
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This configuration option allows systematically rewriting fetch-only URLs
to push-capable URLs when used with push. For instance:
[url "ssh://example.org/"]
pushInsteadOf = "git://example.org/"
This will allow clones of "git://example.org/path/to/repo" to subsequently
push to "ssh://example.org/path/to/repo", without manually configuring
pushurl for that remote.
Includes documentation for the new option, bash completion updates, and
test cases (both that pushInsteadOf applies to push, that it does not
apply to fetch, and that it is ignored when pushURL is already defined).
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git grep" would barf at relative paths pointing outside the current
working directory (or subdirectories thereof). Use quote_path_relative(),
which can handle such cases just fine.
[jc: added tests.]
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the coloring logic processed the patch output one line at a time, we
couldn't easily color code the new blank lines at the end of file.
Reuse the adds_blank_at_eof() function to find where the runs of such
blank lines start, keep track of the line number in the preimage while
processing the patch output one line at a time, and paint the new blank
lines that appear after that line to implement this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "diff --check" logic used to share the same issue as the one fixed for
"git apply" earlier in this series, in that a patch that adds new blank
lines at end could appear as
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
+$
+$
+$
_$
_$
where _ stands for SP and $ shows a end-of-line. Instead of looking at
each line in the patch in the callback, simply count the blank lines from
the end in two versions, and notice the presence of new ones.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "diff --check" code used to conflate trailing-space whitespace error
class with this, but now we have a proper separate error class, we should
check it under blank-at-eof, not trailing-space.
The whitespace error is not about _having_ blank lines at end, but about
adding _new_ blank lines. To keep the message consistent with what is
given by "git apply", call whitespace_error_string() to generate it,
instead of using a hardcoded custom message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The whitespace error of adding blank lines at the end of file should
trigger if you added a non-empty line at the end, if the contents of the
line is full of whitespaces.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git apply" strips new blank lines at EOF under --whitespace=fix option,
but neigher --whitespace=warn nor --whitespace=error paid any attention to
these errors.
Introduce a new whitespace error class, blank-at-eof, to make the
whitespace error handling more consistent.
The patch adds a new "linenr" field to the struct fragment in order to
record which line the hunk started in the input file, but this is needed
solely for reporting purposes. The detection of this class of whitespace
errors cannot be done while parsing a patch like we do for all the other
classes of whitespace errors. It instead has to wait until we find where
to apply the hunk, but at that point, we do not have an access to the
original line number in the input file anymore, hence the new field.
Depending on your point of view, this may be a bugfix that makes warn and
error in line with fix. Or you could call it a new feature. The line
between them is somewhat fuzzy in this case.
Strictly speaking, triggering more errors than before is a change in
behaviour that is not backward compatible, even though the reason for the
change is because the code was not checking for an error that it should
have. People who do not want added blank lines at EOF to trigger an error
can disable the new error class.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command tries to strip blank lines at the end of the file added by a
patch. It is done by first detecting if a hunk in patch has additional
blank lines at the end of itself, and if so checking if such a hunk
applies at the end of file. This patch addresses a bug in the logic to
implement the former (the previous one addressed a bug in the latter).
If the original ends with blank lines, often the patch hunk ends like
this:
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
+$
+$
+$
_$
_$
where _ stands for SP and $ shows a end-of-line. This example patch adds
three trailing blank lines, but the code fails to notice it, because it
only pays attention to added blank lines at the very end of the hunk. In
this example, the three added blank lines do not appear textually at the
end in the patch, even though you can see that they are indeed added at
the end, if you rearrange the diff like this:
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
_$
_$
+$
+$
+$
The fix is not to reset the number of (candidate) added blank lines at the
end when the loop sees a context line that is empty.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
b94f2ed (builtin-apply.c: make it more line oriented, 2008-01-26) broke
the logic used to detect if a hunk adds blank lines at the end of the
file. With the new code after that commit:
- img holds the contents of the file that the hunk is being applied to;
- preimage has the lines the hunk expects to be in img; and
- postimage has the lines the hunk wants to update the part in img that
corresponds to preimage with.
and we need to compare if the last line of preimage (not postimage)
matches the last line of img to see if the hunk applies at the end of the
file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current code just leaves the transport in whatever state
it was in after performing the fetch. For a non-empty clone
over the git protocol, the transport code already
disconnects at the end of the fetch.
But for an empty clone, we leave the connection hanging, and
eventually close the socket when clone exits. This causes
the remote upload-pack to complain "the remote end hung up
unexpectedly". While this message is harmless to the clone
itself, it is unnecessarily scary for a user to see and may
pollute git-daemon logs.
This patch just explicitly calls disconnect after we are
done with the remote end, which sends a flush packet to
upload-pack and cleanly disconnects, avoiding the error
message.
Other transports are unaffected or slightly improved:
- for a non-empty repo over the git protocol, the second
disconnect is a no-op (since we are no longer connected)
- for "walker" transports (like HTTP or FTP), we actually
free some used memory (which previously just sat until
the clone process exits)
- for "rsync", disconnect is always a no-op anyway
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the earlier DWIM patches, certain combination of options defaulted
to the "save" command correctly while certain equally valid combination
did not. For example, "git stash -k" were Ok but "git stash -q -k" did
not work.
This makes the logic of defaulting to "save" much simpler. If there are no
non-flag arguments, it is clear that there is no command word, and we
default to "save" subcommand. This rule prevents "git stash -q apply"
from quietly creating a stash with "apply" as the message.
This also teaches "git stash save" to reject an unknown option. This is
to keep a mistyped "git stash save --quite" from creating a stash with a
message "--quite", and this safety is more important with the new logic
to default to "save" with any option-looking argument without an explicit
comand word.
[jc: this is based on Matthieu's 3-patch series, and a follow-up
discussion, and he and Peff take all the credit; if I have introduced bugs
while reworking, they are mine.]
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were broken by b5373e9. The problem is that the code
marks the month and year with "-1" for "we don't know it
yet", but the month and year code paths were not adjusted to
fill in the current time before doing their calculations
(whereas other units follow a different code path and are
fine).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Until now, there was no coverage of relative date printing
or approxidate parsing routines (mainly because we had no
way of faking the "now" time for relative date calculations,
which made consistent testing impossible).
This new script tries to exercise the basic features of
show_date and approxidate. Most of the tests are just "this
obvious thing works" to prevent future regressions, with a
few exceptions:
- We confirm the fix in 607a9e8 that relative year/month
dates in the latter half of a year round correctly.
- We confirm that the improvements in b5373e9 and 1bddb25
work.
- A few tests are marked to expect failure, which are
regressions recently introduced by the two commits
above.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This file is no longer used since 54bc13c (t8005: Nobody writes Russian in
shift_jis, 2009-06-18).
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A request to clone the repository does not give any "have" but asks for
all the refs we offer with "want". When a request does not ask to clone
the repository fully, but asks to fetch some refs into an empty
repository, it will not give any "have" but its "want" won't ask for all
the refs we offer.
If we suppose (and I would say this is a rather big if) that it makes
sense to distinguish these two cases, a hook cannot reliably do this
alone. The hook can detect lack of "have" and bunch of "want", but there
is no direct way to tell if the other end asked for all refs we offered,
or merely most of them.
Between the time we talked with the other end and the time the hook got
called, we may have acquired more refs or lost some refs in the repository
by concurrent operations. Given that we plan to introduce selective
advertisement of refs with a protocol extension, it would become even more
difficult for hooks to guess between these two cases.
This adds "kind [clone|fetch]" to hook's input, as a stable interface to
allow the hooks to tell these cases apart.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After upload-pack successfully finishes its operation, post-upload-pack
hook can be called for logging purposes.
The hook is passed various pieces of information, one per line, from its
standard input. Currently the following items can be fed to the hook, but
more types of information may be added in the future:
want SHA-1::
40-byte hexadecimal object name the client asked to include in the
resulting pack. Can occur one or more times in the input.
have SHA-1::
40-byte hexadecimal object name the client asked to exclude from
the resulting pack, claiming to have them already. Can occur zero
or more times in the input.
time float::
Number of seconds spent for creating the packfile.
size decimal::
Size of the resulting packfile in bytes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some platforms (IRIX 6.5, Solaris 7) do not provide the 'yes' utility.
Currently, some tests, including t7610 and t9001, try to call this program.
Due to the way the tests are structured, the tests still pass even though
this program is missing. Rather than succeeding by chance, let's provide
an implementation of the simple 'yes' utility in shell for all platforms to
use.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adds a new test file, t9501, that checks HTTP status codes and messages
from gitweb.
Currently, the only tests are for the snapshot feature.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To accommodate additions to the test cases for gitweb, the preamble
from t9500 is now in its own library so that new sets of tests for
gitweb can use the same setup without copying the code.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Brandon Casey