Rename the make_*_path functions so it's clearer what they do, in
particlar make clear what the differnce between make_absolute_path and
make_nonrelative_path is by renaming them real_path and absolute_path
respectively. make_relative_path has an understandable name and is
renamed to relative_path to maintain the name convention.
The function calls have been replaced 1-to-1 in their usage.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also remove entries for fixes that are already present in the
maintenance track.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Prepare draft release notes to 1.7.4.2
gitweb: highlight: replace tabs with spaces
make_absolute_path: return the input path if it points to our buffer
valgrind: ignore SSE-based strlen invalid reads
diff --submodule: split into bite-sized pieces
cherry: split off function to print output lines
branch: split off function that writes tracking info and commit subject
standardize brace placement in struct definitions
compat: make gcc bswap an inline function
enums: omit trailing comma for portability
Conflicts:
RelNotes
* lt/rename-no-extra-copy-detection:
diffcore-rename: improve estimate_similarity() heuristics
diffcore-rename: properly honor the difference between -M and -C
for_each_hash: allow passing a 'void *data' pointer to callback
* mg/placeholders-are-lowercase:
Make <identifier> lowercase in Documentation
Make <identifier> lowercase as per CodingGuidelines
Make <identifier> lowercase as per CodingGuidelines
Make <identifier> lowercase as per CodingGuidelines
CodingGuidelines: downcase placeholders in usage messages
Consider the following code fragment:
/*
* test
*/
vim ":set list" mode shows that the first character on each line is a
tab:
^I/*$
^I * test$
^I */$
By default, the "highlight" program will retain the tabs in the HTML
output:
$ highlight --fragment --syntax c test.c
<span class="hl com">/*</span>
<span class="hl com"> * test</span>
<span class="hl com"> */</span>
vim list mode:
^I<span class="hl com">/*</span>$
<span class="hl com">^I * test</span>$
<span class="hl com">^I */</span>$
In gitweb, this winds up looking something like:
1 /*
2 * test
3 */
I tried both Firefox and Opera and saw the same behavior.
The desired output is:
1 /*
2 * test
3 */
This can be accomplished by specifying "--replace-tabs=8" on the
highlight command line.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Acked-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some codepaths call make_absolute_path with its own return value as
input. In such a cases, return the path immediately.
This fixes a valgrind-discovered error, whereby we tried to copy a
string onto itself.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some versions of strlen use SSE to speed up the calculation and load 4
bytes at a time, even if it means reading past the end of the
allocated memory. This read is safe and when the strlen function is
inlined, it is not replaced by valgrind, which reports a
false-possitive.
Tell valgrind to ignore this particular error, as the read is, in
fact, safe. Current upstream-released version 3.6.1 is affected. Some
distributions have this fixed in their latest versions.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
trp_gen is not a statement or function call, so it should not be
followed with a semicolon. Noticed by gcc -pedantic.
vcs-svn/repo_tree.c:41:81: warning: ISO C does not allow extra ';'
outside of a function [-pedantic]
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce two functions:
- prepare_submodule_summary prepares the revision walker
to list changes in a submodule. That is, it:
* finds merge bases between the commits pointed to this
path from before ("left") and after ("right") the change;
* checks whether this is a fast-forward or fast-backward;
* prepares a revision walk to list commits in the symmetric
difference between the commits at each endpoint.
It returns nonzero on error.
- print_submodule_summary runs the revision walk and saves
the result to a strbuf in --left-right format.
The goal is just readability. No functional change intended.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Readers uninterested in the details of "git cherry"'s output format
can see
print_commit('-', commit, verbose, abbrev);
and ignore the details.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a add_verbose_info function that takes care of adding
- an abbreviated object name;
- a summary of the form [ahead x, behind y] of the relationship
to the corresponding upstream branch;
- a one line commit subject
for the tip commit of a branch, for use in "git branch -v" output.
No functional change intended. This just unindents the code a little
and makes it easier to skip on first reading.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a struct definitions, unlike functions, the prevailing style is for
the opening brace to go on the same line as the struct name, like so:
struct foo {
int bar;
char *baz;
};
Indeed, grepping for 'struct [a-z_]* {$' yields about 5 times as many
matches as 'struct [a-z_]*$'.
Linus sayeth:
Heretic people all over the world have claimed that this inconsistency
is ... well ... inconsistent, but all right-thinking people know that
(a) K&R are _right_ and (b) K&R are right.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this change, gcc -pedantic warns:
cache.h: In function 'ce_to_dtype':
cache.h:270:21: warning: ISO C forbids braced-groups within expressions [-pedantic]
An inline function is more readable anyway.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since v1.7.2-rc0~23^2~2 (Add per-repository eol normalization,
2010-05-19), building with gcc -std=gnu89 -pedantic produces warnings
like the following:
convert.c:21:11: warning: comma at end of enumerator list [-pedantic]
gcc is right to complain --- these commas are not permitted in C89.
In the spirit of v1.7.2-rc0~32^2~16 (2010-05-14), remove them.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As "gcc -pedantic" notices, a two's complement 1-bit signed integer
cannot represent the value '1'.
dir.c: In function 'init_pathspec':
dir.c:1291:4: warning: overflow in implicit constant conversion [-Woverflow]
In the spirit of v1.7.1-rc1~10 (2010-04-06), 'unsigned' is what was
intended, so let's make the flags unsigned.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Give an example on how to bisect when older revisions need a hot-fix to
build, run or test. Triggered by the binutils/kernel issue at
http://thread.gmane.org/gmane.comp.gnu.binutils/52601/focus=1112779
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Streamline the presentation of "bisect run" by removing one example
which does not introduce new concepts.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sp/maint-fd-limit:
sha1_file.c: Don't retain open fds on small packs
mingw: add minimum getrlimit() compatibility stub
Limit file descriptors used by packs
* 'jk/doc-credits' of git://github.com/peff/git:
docs: point git.txt author credits to git-scm.com
doc: add missing git footers
doc: drop author/documentation sections from most pages
Variables from the inherited environment that are meaningful to git
can break tests in undesirable ways. For example,
GIT_PAGER=more sh t5400-send-pack.sh -v -i
hangs. So unset all environment variables in the GIT_ namespace in
test-lib, with a few exceptions:
- GIT_TRACE* are useful for tracking down bugs exhibited by a failing
test;
- GIT_DEBUG* are GIT_TRACE variables by another name, practically
speaking. They should probably be tweaked to follow the
GIT_TRACE_foo scheme and use trace_printf machinery some time.
- GIT_USE_LOOKUP from v1.5.6-rc0~134^2~1 (sha1-lookup: more memory
efficient search in sorted list of SHA-1, 2007-12-29) is about
trying an alternate implementation strategy rather than changing
semantics and it can be useful to compare performance with and
without it set.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that test-lib sets $HOME to protect against pollution from user
settings, GIT_CONFIG_NOGLOBAL is not needed for use by the test
suite any more. And as luck would have it, a quick code search
reveals no other users in the wild.
This patch does not affect GIT_CONFIG_NOSYSTEM, which is still
needed.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-lib sets $HOME to protect against pollution from user settings,
so setting GIT_ATTR_NOGLOBAL would be redundant. Simplify by
eliminating support for that environment variable altogether.
GIT_ATTR_NOGLOBAL was introduced in v1.7.4-rc0~208^2 (Add global and
system-wide gitattributes, 2010-09-01) as an undocumented feature for
use by the test suite. It never ended up being used (neither within
git.git nor in other projects).
This patch does not affect GIT_ATTR_NOSYSTEM, which should still be
useful.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Set GIT_ATTR_NOSYSTEM in test-lib to make tests more reliable in two
ways:
- an invalid GIT_ATTR_NOSYSTEM setting should not cause tests to fail
with "fatal: bad config value for 'GIT_ATTR_NOSYSTEM'".
- /etc/gitattributes should not change the outcome of tests.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After v0.99.7~99 (Retire support for old environment variables,
2005-09-09), there is no more need to unset a stray AUTHOR_NAME
variable that might have entered the test environment.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the client requests both multi_ack_detailed and no-done then
upload-pack is free to immediately send a PACK following its first
'ACK %s ready' message. The upload-pack response actually winds
up being:
ACK %s common
... (maybe more) ...
ACK %s ready
NAK
ACK %s
PACK.... the pack stream ....
For smart HTTP connections this saves one HTTP RPC, reducing
the overall latency for a trivial fetch. For git:// and ssh://
a no-done option slightly reduces latency by removing one
server->client->server round-trip at the end of the common
ancestor negotiation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If enabled on the connection "multi_ack_detailed no-done" as a
pair allows the remote upload-pack process to send a PACK down
to the client as soon as a "ACK %s ready" message was also sent.
Over git:// and ssh:// where a bi-directional stream is in place
this has very little difference over the classical version that
waits for the client to send a "done\n" line by itself. It does
slightly reduce the latency involved to start the pack stream as
there is one less round-trip from client->server required.
Over smart HTTP this avoids needing to send a final RPC that has
all of the prior common objects. Instead the server is able to
return a pack as soon as its ready to. For many common users the
smart HTTP fetch is now just 2 requests: GET .../info/refs, and
a POST .../git-upload-pack to not only negotiate but also receive
the pack stream. Only users who have more than 32 local unshared
commits with the remote will need additional requests to negotiate
a common merge base.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a client is merely following the remote (and has not made any
new commits itself), all "have %s" lines sent by the client will be
common to the server. As all lines are common upload-pack never
calls ok_to_give_up() and does not compute if it has a good cut
point in the commit graph.
Without this computation the following client is going to send all
tagged commits, as these were determined to be COMMON_REF during the
initial advertisement, but the client does not parse their history
to transitively pass the COMMON flag and empty its queue of commits.
For git.git with 339 commit tags, it takes clients 11 rounds of
negotation to fully send all tagged commits and exhaust its queue
of things to send as common. This is pretty slow for a client that
has not done any local development activity.
Force computing ok_to_give_up() and send "ACK %s ready" at the end
of the current round if this round only contained common objects
and ok_to_give_up() was therefore not called. This may allow the
client to break early, avoiding transmission of the COMMON_REFs.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If multi_ack_detailed was selected in the protocol capabilities
(both client and server are >= Git 1.6.6) the upload-pack side will
send "ACK %s ready" when it knows how to safely cut the graph and
produce a reasonable pack for the want list that was already sent
on the connection.
Upon receiving "ACK %s ready" there is no point in looking at
the remaining commits inside of rev_list. Sending additional
"have %s" lines to the remote will not construct a smaller pack.
It is unlikely a commit older than the current cut point will have
a better delta base than the cut point itself has.
The original design of this code had fetch-pack empty rev_list by
marking a commit and its transitive ancestors COMMON whenever the
remote side said "ACK %s {continue,common}" and skipping over any
already COMMON commits during get_rev(). This approach does not
work when most of rev_list is actually COMMON_REF, commits that
are pointed to by a reference on the remote, which exist locally,
and which have not yet been sent to the remote as a "have %s" line.
Most of the common references are tags in the ref/tags namespace,
using points in the commit graph that are more than 1 commit apart.
In git.git itself, this is currently 340 tags, 339 of which point to
commits in the commit graph. fetch-pack pushes all of these into
rev_list, but is unable to mark them COMMON and discard during a
remote's "ACK %s {continue,common}" because it does not parse through
the entire parent chain. Not parsing the entire parent chain is
an optimization to avoid walking back to the roots of the repository.
Assuming the client is only following the remote (and does not make
its own local commits), the client needs 11 rounds to spin through
the entire list of tags (32 commits per round, ceil(339/32) == 11).
Unfortunately the server knows on the first "have %s" line that
it can produce a good pack, and does not need to see the remaining
320 tags in the other 10 rounds.
Over git:// and ssh:// this isn't as bad as it sounds, the client is
only transmitting an extra 16,000 bytes that it doesn't need to send.
Over smart HTTP, the client must do an additional 10 HTTP POST
requests, each of which incurs round-trip latency, and must upload
the entire state vector of all known common objects. On the final
POST request, this is 16 KiB worth of data.
Fix all of this by clearing rev_list as soon as the remote side
says it can construct a pack.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
