That is what the documentation says, but the code pretends as if all the
known whitespace error tokens were given.
Among the whitespace error tokens, there is one kind that loosens the rule
when set: cr-at-eol. Which means that whitespace error token that is set
to true ignores a newly introduced CR at the end, which is inconsistent
with the documentation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a CR is accidentally added at the end of a C source file in the git
project tree, "git diff --check" doesn't detect it as an error.
$ echo abQ | tr Q '\015' >>fast-import.c
$ git diff --check
I think this is because the "whitespace" attribute is set to *.[ch] files
without specifying what kind of errors are caught. It makes git "notice
all types of errors" (as described in the documentation), but I think it
is incorrectly setting cr-at-eol, too, and hides this error.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test wanted to make sure that cherry-pick exits with status 1,
but with the way it was placed after "git checkout master &&" meant
that it could have misjudged success if checkout barfed with the
same failure status.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.2:
git-show-ref.txt: remove word and make consistent
git-svn documentation: fix typo in 'rebase vs. pull/merge' section
use xstrdup, not strdup in ll-merge.c
* maint-1.6.1:
git-show-ref.txt: remove word and make consistent
git-svn documentation: fix typo in 'rebase vs. pull/merge' section
use xstrdup, not strdup in ll-merge.c
* maint-1.6.0:
git-show-ref.txt: remove word and make consistent
git-svn documentation: fix typo in 'rebase vs. pull/merge' section
use xstrdup, not strdup in ll-merge.c
Under is better than in because of the nested nature of the .git
directory.
"also using" sounds a little odd, plus we say combined with later on so
just use that.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't call git_config after parsing the command line options, otherwise
the config settings will override any settings made by the command line.
This can be seen by setting add.ignore_errors and then specifying
--no-ignore-errors when using git-add.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the minimimum required libcurl version for the http.sslKey option
to 7.9.3. Previously, preprocessor macros checked for >= 7.9.2, which
is incorrect because CURLOPT_SSLKEY was introduced in 7.9.3. This now
allows git to compile with libcurl 7.9.2.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, the refspec "<src>:" would be expanded to
"<src>:refs/heads/". Instead, treat an empty <dst> just like refspecs
without a colon.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this patch, symbolic links are turned into empty files.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Cygwin, poll() reports POLLIN even for file descriptors that have
reached their end. This caused git upload-archive to be stuck in an
infinite loop, as it only looked at the POLLIN flag.
In addition to POLLIN, check if read() returned 0, which indicates
end-of-file, and keep looping only as long as at least one of the file
descriptors has input. This lets the following command finish on its
own when run in a git repository on Cygwin, instead of it getting stuck
after printing all file names:
$ git archive -v --remote . HEAD >/dev/null
Reported-by: Bob Kagy <bobkagy@gmail.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the old regex
^[ \t]*(([ \t]*[A-Za-z_][A-Za-z_0-9]*){2,}[ \t]*\([^;]*)$
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
you can backtrack arbitrarily from [A-Za-z_0-9]* into [A-Za-z_], thus
causing an exponential number of backtracks. Ironically it also causes
the regex not to work as intended; for example "catch" can match the
underlined part of the regex, the first repetition matching "c" and
the second matching "atch".
The replacement regex avoids this problem, because it makes sure that
at least a space/tab is eaten on each repetition. In other words,
a suffix of a repetition can never be a prefix of the next repetition.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Shifting 'unsigned char' or 'unsigned short' left can result in sign
extension errors, since the C integer promotion rules means that the
unsigned char/short will get implicitly promoted to a signed 'int' due to
the shift (or due to other operations).
This normally doesn't matter, but if you shift things up sufficiently, it
will now set the sign bit in 'int', and a subsequent cast to a bigger type
(eg 'long' or 'unsigned long') will now sign-extend the value despite the
original expression being unsigned.
One example of this would be something like
unsigned long size;
unsigned char c;
size += c << 24;
where despite all the variables being unsigned, 'c << 24' ends up being a
signed entity, and will get sign-extended when then doing the addition in
an 'unsigned long' type.
Since git uses 'unsigned char' pointers extensively, we actually have this
bug in a couple of places.
I may have missed some, but this is the result of looking at
git grep '[^0-9 ][ ]*<<[ ][a-z]' -- '*.c' '*.h'
git grep '<<[ ]*24'
which catches at least the common byte cases (shifting variables by a
variable amount, and shifting by 24 bits).
I also grepped for just 'unsigned char' variables in general, and
converted the ones that most obviously ended up getting implicitly cast
immediately anyway (eg hash_name(), encode_85()).
In addition to just avoiding 'unsigned char', this patch also tries to use
a common idiom for the delta header size thing. We had three different
variations on it: "& 0x7fUL" in one place (getting the sign extension
right), and "& ~0x80" and "& 0x7f" in two other places (not getting it
right). Apart from making them all just avoid using "unsigned char" at
all, I also unified them to then use a simple "& 0x7f".
I considered making a sparse extension which warns about doing implicit
casts from unsigned types to signed types, but it gets rather complex very
quickly, so this is just a hack.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise, a fluky allocation failure would cause merge
configuration settings to be silently ignored.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rewrite the gc section using unresolved and resolved instead of "not
recorded". Add plurals and missing articles. Make some sentences have
consistent tense. Try and be more active by removing "that" and
simplifying sentences.
The terms "hand-resolve" and "hand resolve" were used, so just use "hand
resolve" to be more consistent.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-send-email docs do not mention except in the usage lines
the combined patch formatting/sending ability of git-send-email.
This patch expands on the possible arguments to git-send-email
and explains the meaning of the rev-list argument.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
it was introduced in 68a163c9b4
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Jöhännës "Dschö" Schindëlin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch-pack runs the sideband demultiplexer using start_async(). This
facility requires that the asynchronously executed function closes the
output file descriptor (see Documentation/technical/api-run-command.txt).
But the sideband demultiplexer did not do that. This fixes it.
In certain error situations this could lock up a fetch operation on
Windows because the asynchronous function is run in a thread; by not
closing the output fd the reading end never got EOF and waited for more
data indefinitely. On Unix this is not a problem because the asynchronous
function is run in a separate process, which exits after the function ends
and so implicitly closes the output.
Since the pack that is sent over the wire encodes the number of objects in
the stream, during normal operation the reading end knows when the stream
ends and terminates by itself, and does not lock up.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix the way in which the configure script handles --without-iconv
(and --with-iconv=no), which it used to essentially ignore.
Also fix the way the configure script determines the value of
NEEDS_LIBICONV, which would be incorrectly set to 'YesPlease' on
systems that lack iconv entirely.
Signed-off-by: Marco Nelissen <marcone@xs4all.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, "git remote -v" lists all urls whereas "git remote show
$remote" shows only the first. Make it so that both show all.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add references to the gitworkflows(7) manpage added in f948dd8
(Documentation: add manpage about workflows, 2008-10-19) to both
gittutorial(1) and git(1), so that new users might actually discover
and read it.
Noticed by Randal L. Schwartz.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 1.4.4.5 (49ba83fb67 "Add virtualization support to git-daemon")
git daemon enters an infinite loop and never terminates if a client
hides any extra arguments in the initial request line which is not
exactly "\0host=blah\0".
Since that change, a client must never insert additional extra
arguments, or attempt to use any argument other than "host=", as
any daemon will get stuck parsing the request line and will never
complete the request.
Since the client can't tell if the daemon is patched or not, it
is not possible to know if additional extra args might actually be
able to be safely requested.
If we ever need to extend the git daemon protocol to support a new
feature, we may have to do something like this to the exchange:
# If both support git:// v2
#
C: 000cgit://v2
S: 0010ok host user
C: 0018host git.kernel.org
C: 0027git-upload-pack /pub/linux-2.6.git
S: ...git-upload-pack header...
# If client supports git:// v2, server does not:
#
C: 000cgit://v2
S: <EOF>
C: 003bgit-upload-pack /pub/linux-2.6.git\0host=git.kernel.org\0
S: ...git-upload-pack header...
This requires the client to create two TCP connections to talk to
an older git daemon, however all daemons since the introduction of
daemon.c will safely reject the unknown "git://v2" command request,
so the client can quite easily determine the server supports an
older protocol.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Set slot->local to NULL after doing a fclose() on the file it points
to. This prevents the passing of a FILE* pointer to a fclose()'d file
to ftell() in http.c::run_active_slot().
This issue was raised by Clemens Buchacher on 30th May 2009:
http://www.spinics.net/lists/git/msg104623.html
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command "git grep -w ''" dies as soon as it encounters an empty line,
reporting (wrongly) that "regexp returned nonsense". The first hunk of
this patch relaxes the sanity check that is responsible for that,
allowing matches to start at the end.
The second hunk complements it by making sure that empty matches are
rejected if -w was specified, as they are not really words.
GNU grep does the same:
$ echo foo | grep -c ''
1
$ echo foo | grep -c -w ''
0
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When trying to see if the same path exists in the parent, we ran
"diff-tree" with pathspec set to the path we are interested in with the
parent, and expect either to have exactly one resulting filepair (either
"changed from the parent", "created when there was none") or nothing (when
there is no change from the parent).
If the path used to be a directory, however, we will also see unbounded
number of entries that talk about the files that used to exist underneath
the directory in question. Correctly pick only the entry that describes
the path we are interested in in such a case (namely, the creation of the
path as a regular file).
Noticed by Ben Willard.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove a debugging print that snuck in at 7a26e65 (Revert
"git-add--interactive: remove hunk coalescing", 2009-05-16).
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cb/maint-1.6.0-xdl-merge-fix:
Change xdl_merge to generate output even for null merges
t6023: merge-file fails to output anything for a degenerate merge
Conflicts:
xdiff/xmerge.c
* jc/maint-add-p-coalesce-fix:
t3701: ensure correctly set up repository after skipped tests
Revert "git-add--interactive: remove hunk coalescing"
Splitting a hunk that adds a line at the top fails in "add -p"
If a zero-length match is encountered, break out of loop and show the rest
of the line uncoloured. Otherwise we'd be looping forever, trying to make
progress by advancing the pointer by zero characters.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The following is an easy mistake to make for users coming from version
control systems with an "update and commit"-style workflow.
1. git pull
2. resolve conflicts
3. git pull
Step 3 overrides MERGE_HEAD, starting a new merge with dirty index.
IOW, probably not what the user intended. Instead, refuse to merge
again if a merge is in progress.
Reported-by: Dave Olszewski <cxreg@pobox.com>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes commands such as `git for-each-ref --format='%(refname)'`,
which are used heavily by the bash_completion code, run about 6 times
faster on an uncached repository (3 s intead of 18 s on my linux-2.6
repository with several remotes).
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent discussion on the list showed some comments in favour of a
stash/pop workflow:
http://marc.info/?l=git&m=124234911423358&w=2http://marc.info/?l=git&m=124235348327711&w=2
Change the stash documentation and examples to document pop in its own
right (and apply in terms of pop), and use stash/pop in the examples.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In case of an empty list, the search for its tail caused a
NULL-pointer dereference.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Reported-by: Erik Faye-Lund <kusmabite@googlemail.com>
Acked-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
