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>
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>
* cb/maint-1.6.3-grep-relative-up:
grep: accept relative paths outside current working directory
grep: fix exit status if external_grep() punts
Conflicts:
t/t7002-grep.sh
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>
* jc/mailinfo-scissors:
mailinfo.scissors: new configuration
am/mailinfo: Disable scissors processing by default
Documentation: describe the scissors mark support of "git am"
Teach mailinfo to ignore everything before -- >8 -- mark
builtin-mailinfo.c: fix confusing internal API to mailinfo()
* tr/reset-checkout-patch:
stash: simplify defaulting to "save" and reject unknown options
Make test case number unique
tests: disable interactive hunk selection tests if perl is not available
DWIM 'git stash save -p' for 'git stash -p'
Implement 'git stash save --patch'
Implement 'git checkout --patch'
Implement 'git reset --patch'
builtin-add: refactor the meat of interactive_add()
Add a small patch-mode testing library
git-apply--interactive: Refactor patch mode code
Make 'git stash -k' a short form for 'git stash save --keep-index'
"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>
* maint-1.6.3:
git-clone: add missing comma in --reference documentation
git-cvsserver: no longer use deprecated 'git-subcommand' commands
clone: disconnect transport after fetching
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>
* lt/approxidate:
fix approxidate parsing of relative months and years
tests: add date printing and parsing tests
refactor test-date interface
Add date formatting and parsing functions relative to a given time
Further 'approxidate' improvements
Improve on 'approxidate'
Conflicts:
date.c
* mr/gitweb-snapshot:
gitweb: add t9501 tests for checking HTTP status codes
gitweb: split test suite into library and tests
gitweb: improve snapshot error handling
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>
