The MSVC headers typedef errcode as int, and thus confused the compiler in
the K&R style definition. ANSI style deconfuses it.
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
MSVC does not understand this C99 style.
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These spaces immediately before the end of lines are unnecessary.
While at it, instead of using a single string literal with backslashes
at end of each line, split the lines into individual string literals
and tell the compiler to concatenate them.
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git bundle -h" gives a single long line that is hard to read. Rewrite it
into a multi-line format similar to the one used by other commands, e.g
"git stash -h".
Signed-off-by: Thiago Farina <tfransosi@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When trying to get a list of remote tags to see if we need to fetch
any we were doing a linear search for the matching tag ref for the
tag^{} commit entries. This proves to be incredibly slow for large
numbers of tags. Rewrite the function so that we build up a
string_list of refs to fetch and then process that instead.
As an extreme example, for a repository with 50000 tags (and just a
single commit on a single branch), a fetch that does nothing goes from
~1m50s to ~4.1s.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we do not read a password from the command line, and there are no
passwords stored in .cvspass, we have to initialize the password with
just "A".
This fixes a regression introduced by 3fb9d582 (Do not scramble
password read from .cvspass).
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tf/diff-whitespace-incomplete-line:
xutils: Fix xdl_recmatch() on incomplete lines
xutils: Fix hashing an incomplete line with whitespaces at the end
* 'jc/maint-1.6.0-blank-at-eof' (early part):
diff.c: emit_add_line() takes only the rest of the line
diff.c: split emit_line() from the first char and the rest of the line
* 'jc/maint-1.6.0-blank-at-eof' (early part):
diff --whitespace: fix blank lines at end
core.whitespace: split trailing-space into blank-at-{eol,eof}
diff --color: color blank-at-eof
diff --whitespace=warn/error: fix blank-at-eof check
diff --whitespace=warn/error: obey blank-at-eof
diff.c: the builtin_diff() deals with only two-file comparison
apply --whitespace: warn blank but not necessarily empty lines at EOF
apply --whitespace=warn/error: diagnose blank at EOF
apply.c: split check_whitespace() into two
apply --whitespace=fix: detect new blank lines at eof correctly
apply --whitespace=fix: fix handling of blank lines at the eof
We used to send the old and new contents more or less straight out to the
output with only the original "old is red, new is green" colouring. Now
all the necessary support routines have been prepared, call them with a
line of data at a time from the output code and have them check and color
whitespace errors in exactly the same way as they are called from the low
level diff callback routines.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As the first character on the line that is fed to this function is always
"+", it is pointless to send that along with the rest of the line.
This change will make it easier to reuse the logic when emitting the
rewrite diff, as we do not want to copy a line only to add "+"/"-"/" "
immediately before its first character when we produce rewrite diff
output.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A new helper function emit_line_0() takes the first line of diff output
(typically "-", " ", or "+") separately from the remainder of the line.
No other functional changes.
This change will make it easier to reuse the logic when emitting the
rewrite diff, as we do not want to copy a line only to add "+"/"-"/" "
immediately before its first character when we produce rewrite diff
output.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move function, type, and structure definitions for fill_mmfile(),
count_trailing_blank(), check_blank_at_eof(), emit_line(),
new_blank_line_at_eof(), emit_add_line(), sane_truncate_fn, and
emit_callback up in the file, so that they can be refactored into helper
functions and reused by codepath for emitting rewrite patches.
This only moves the lines around to make the next two patches easier to
read.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
An earlier 59b8d38 (http.c: remove verification of remote packs) left
the variable "url" uninitialized; "goto cleanup" codepath can free it
which is not very nice.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since OS X 10.6 the variable $SECURITYSESSIONID does not exist anymore,
so lets look for the $TERM_PROGRAM variable as backup.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Due to problems at cam.org, my nico@cam.org email address is no longer
valid. From now on, nico@fluxnic.net should be used instead.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A command line
$ git archive -o my-v2.0.zip v2.0
almost certainly wants the output in zip format, even though it does not
specify any --format option.
When --format is not given, but output filename is, try to infer what
format is requested from the filename extension. Currently this code only
knows about '.zip'. When the format is unspecified and the filename does
not tell us, the output will be in 'tar' format as before.
Of course, an explicit --format will not trigger this guesswork.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
James Bardin noted that the completion spewed warnings when no git config
file is present. This is likely a bug to be fixed in git config, but it's
also good to simplify the completion code by using the --get-regexp option
as Jeff King pointed out.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
Trivially-acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The '-o' option is commonly used in many tools to specify the output file.
Typing '--output' every time is a bit too long to be a practical alternative
to redirecting output. But specifying the output name has the advantage of
making possible to guess the desired output format by filename extension.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
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>
git-push is not currently using -n for anything else, and it seems
unlikely we will want to use it to mean anything else in the future,
so add it as an alias for convenience.
Signed-off-by: Nelson Elhage <nelhage@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
60c2993 (Documentation/git-commit.txt: describe --dry-run, 2009-08-15)
wanted to update the documentation to say that "git status" is not the
same as "git commit --dry-run" anymore, but it screwed up and also added
the description of --dry-run that was already present.
Noticed by Johannes Gilger.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A local clone without hardlinks copies all objects, including dangling
ones, to the new repository. Since the mtimes are renewed, those
dangling objects cannot be pruned by "git gc --prune", even if they
would have been old enough for pruning in the original repository.
Instead, preserve mtime during copy. "git gc --prune" will then work
in the clone just like it did in the original.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were several unchecked use of fdopen(); replace them with xfdopen()
that checks and dies.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is the same fix to use write_str_in_full() helper to write a constant
string out without counting the length of it ourselves.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* db/vcs-helper:
Makefile: remove remnant of separate http/https/ftp helpers
Use a clearer style to issue commands to remote helpers
Make the "traditionally-supported" URLs a special case
Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
Makefile: do not link three copies of git-remote-* programs
Makefile: git-http-fetch does not need expat
http-fetch: Fix Makefile dependancies
Add transport native helper executables to .gitignore
git-http-fetch: not a builtin
Use an external program to implement fetching with curl
Add support for external programs for handling native fetches
In 2d14d65 (Use a clearer style to issue commands to remote helpers,
2009-09-03) I happened to notice two changes like this:
- write_in_full(helper->in, "list\n", 5);
+
+ strbuf_addstr(&buf, "list\n");
+ write_in_full(helper->in, buf.buf, buf.len);
+ strbuf_reset(&buf);
IMHO, it would be better to define a new function,
static inline ssize_t write_str_in_full(int fd, const char *str)
{
return write_in_full(fd, str, strlen(str));
}
and then use it like this:
- strbuf_addstr(&buf, "list\n");
- write_in_full(helper->in, buf.buf, buf.len);
- strbuf_reset(&buf);
+ write_str_in_full(helper->in, "list\n");
Thus not requiring the added allocation, and still avoiding
the maintenance risk of literal string lengths.
These days, compilers are good enough that strlen("literal")
imposes no run-time cost.
Transformed via this:
perl -pi -e \
's/write_in_full\((.*?), (".*?"), \d+\)/write_str_in_full($1, $2)/'\
$(git grep -l 'write_in_full.*"')
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's now similar wrapped the same way as in Documentation/git.txt, and
fits in a 67 characters wide terminal.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
