Commit d24fbca (Remove Git's support for smoke testing - 2011-12-23)
removed the smoke test support from the test suite but it was
re-added by commit 342e9ef (Introduce a performance testing
framework - 2012-02-17). This appears to be the result of a
mis-rebase, since re-adding the smoke testing infrastructure does
not relate to the subject of that commit.
The current 'smoke' target is broken since the 'harness' script it
uses no longer exists, so just reapply this section of commit d24fbca
and remove all of the smoke testing section in the makefile.
Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/gitweb-install-doc:
gitweb/INSTALL: GITWEB_CONFIG_SYSTEM is for backward compatibility
gitweb/INSTALL: Simplify description of GITWEB_CONFIG_SYSTEM
Merge branch 'rt/commentchar-fmt-merge-msg' into maint
* rt/commentchar-fmt-merge-msg:
t6200: avoid path mangling issue on Windows
fmt-merge-msg: use core.commentchar in tag signatures completely
fmt-merge-msg: respect core.commentchar in people credits
"git merge $(git rev-parse v1.8.2)" behaved quite differently from
"git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did
not pay much attention to the annotated tag payload. Make the code
notice the type of the tag object, in addition to the dwim_ref()
based classification the current code uses (i.e. the name appears in
refs/tags/) to decide when to special case merging of tags.
* jc/merge-tag-object:
t6200: test message for merging of an annotated tag
t6200: use test_config/test_unconfig
merge: a random object may not necssarily be a commit
completion: remove duplicate block for "git commit -c"
Remove one of two consecutive, identical blocks for "git commit -c".
This was caused by a mechanical mismerge at d931e2fb252e (Merge
branch 'mp/complete-paths', 2013-02-08). The side branch wanted to
add this block at fea16b47 but the same fix was done independently
at 685397585 already.
Signed-off-by: Mårten Kongstad <marten.kongstad@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
cherry-pick/revert: make usage say '<commit-ish>...'
The usage string for cherry-pick and revert has never been updated to
reflect their ability to handle multiple commits. Other documentation is
already correct.
Signed-off-by: Kevin Bracey <kevin@bracey.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ta/glossary:
glossary: improve definitions of refspec and pathspec
The name of the hash function is "SHA-1", not "SHA1"
glossary: improve description of SHA-1 related topics
glossary: remove outdated/misleading/irrelevant entries
Improve documentation to illustrate "push authenticated, fetch
anonymous" configuration for smart HTTP servers.
* jk/doc-http-backend:
doc/http-backend: match query-string in apache half-auth example
doc/http-backend: give some lighttpd config examples
doc/http-backend: clarify "half-auth" repo configuration
We signal presense of untracked files by adding a per-cent sign '%'
to the prompt. But because '%' is used as an escape character to
introduce prompt customization in zsh (just like bash prompt uses
'\' to escape '\u', '\h', etc.), we need to say '%%' to get a
literal per-cent.
Helped-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
receive-pack: close sideband fd on early pack errors
Since commit a22e6f8 (receive-pack: send pack-processing
stderr over sideband, 2012-09-21), receive-pack will start
an async sideband thread to copy the stderr from our
index-pack or unpack-objects child to the client. We hand
the thread's input descriptor to unpack(), which puts it in
the "err" member of the "struct child_process".
After unpack() returns, we use finish_async() to reap the
sideband thread. The thread is only ready to die when it
gets EOF on its pipe, which is connected to the err
descriptor. So we expect all of the write ends of that pipe
to be closed as part of unpack().
Normally, this works fine. After start_command forks, it
closes the parent copy of the descriptor. Then once the
child exits (whether it was successful or not), that closes
the only remaining writer.
However, there is one code-path in unpack() that does not
handle this. Before we decide which of unpack-objects or
index-pack to use, we read the pack header ourselves to see
how many objects it contains. If there is an error here, we
exit without running either sub-command, the pipe descriptor
remains open, and we are in a deadlock, waiting for the
sideband thread to die (which is in turn waiting for us to
close the pipe).
We can fix this by making sure that unpack() always closes
the pipe before returning.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
MSYS bash interprets the slash in the argument core.commentchar="/"
as root directory and mangles it into a Windows style path. Use a
different core.commentchar to dodge the issue.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git fast-import expects an extra newline after the commit message data,
but we are adding it only on hg-git compat mode, which is why the
bidirectionality tests pass.
We should add it unconditionally.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb/INSTALL: GITWEB_CONFIG_SYSTEM is for backward compatibility
Highlight that CONFIG_SYSTEM and /etc/gitweb.conf are meant to be
the fallback configuration file in BUGS section of gitweb.conf
documentation. This will hopefully help people who expect them to
be a common default, which unfortunately came later in the history.
split_ident_line() can leave us with the pointers date_begin, date_end,
tz_begin and tz_end all set to NULL. Check them before use and supply
the same fallback values as in the case of a negative return code from
split_ident_line().
The "(unknown)" is not actually shown in the output, though, because it
will be converted to a number (zero) eventually.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Centralize the parsing of the date and time zone strings in the new
helper function show_ident_date() and make sure it checks the pointers
provided by split_ident_line() for NULL before use.
Reported-by: Ivan Lyapunov <dront78@gmail.com> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "cat-file -p" prints commits, it shows them in their
raw format, since git's format is already human-readable.
For tags, however, we print the whole thing raw except for
one thing: we convert the timestamp on the tagger line into a
human-readable date.
This dates all the way back to a0f15fa (Pretty-print tagger
dates, 2006-03-01). At that time there was no other way to
pretty-print a tag. These days, however, neither of those
matters much. The normal way to pretty-print a tag is with
"git show", which is much more flexible than "cat-file -p".
Commit a0f15fa also built "verify-tag --verbose" (and
subsequently "tag -v") around the "cat-file -p" output.
However, that behavior was lost in commit 62e09ce (Make git
tag a builtin, 2007-07-20), and we went back to printing
the raw tag contents. Nobody seems to have noticed the bug
since then (and it is arguably a saner behavior anyway, as
it shows the actual bytes for which we verified the
signature).
Let's drop the tagger-date formatting for "cat-file -p". It
makes us more consistent with cat-file's commit
pretty-printer, and as a bonus, we can drop the hand-rolled
tag parsing code in cat-file (which happened to behave
inconsistently with the tag pretty-printing code elsewhere).
This is a change of output format, so it's possible that
some callers could considered this a regression. However,
the original behavior was arguably a bug (due to the
inconsistency with commits), likely nobody was relying on it
(even we do not use it ourselves these days), and anyone
relying on the "-p" pretty-printer should be able to expect
a change in the output format (i.e., while "cat-file" is
plumbing, the output format of "-p" was never guaranteed to
be stable).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
run-command: use thread-aware die_is_recursing routine
If we die from an async thread, we do not actually exit the
program, but just kill the thread. This confuses the static
counter in usage.c's default die_is_recursing function; it
updates the counter once for the thread death, and then when
the main program calls die() itself, it erroneously thinks
we are recursing. The end result is that we print "recursion
detected in die handler" instead of the real error in such a
case (the easiest way to trigger this is having a remote
connection hang up while running a sideband demultiplexer).
This patch solves it by using a per-thread counter when the
async_die function is installed; we detect recursion in each
thread (including the main one), but they do not step on
each other's toes.
Other threaded code does not need to worry about this, as
they do not install specialized die handlers; they just let
a die() from a sub-thread take down the whole program.
Since we are overriding the default recursion-check
function, there is an interesting corner case that is not a
problem, but bears some explanation. Imagine the main thread
calls die(), and then in the die_routine starts an async
call. We will switch to using thread-local storage, which
starts at 0, for the main thread's counter, even though
the original counter was actually at 1. That's OK, though,
for two reasons:
1. It would miss only the first level of recursion, and
would still find recursive failures inside the async
helper.
2. We do not currently and are not likely to start doing
anything as heavyweight as starting an async routine
from within a die routine or helper function.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When any git code calls die or die_errno, we use a counter
to detect recursion into the die functions from any of the
helper functions. However, such a simple counter is not good
enough for threaded programs, which may call die from a
sub-thread, killing only the sub-thread (but incrementing
the counter for everyone).
Rather than try to deal with threads ourselves here, let's
just allow callers to plug in their own recursion-detection
function. This is similar to how we handle the die routine
(the caller plugs in a die routine which may kill only the
sub-thread).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
help.c: add a compatibility comment to cmd_version()
External projects have been known to parse the output of
"git version". Help prevent future authors from changing
its format by adding a comment to its implementation.
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
glossary: improve definitions of refspec and pathspec
The exact definition of "refspec" can be found in git-fetch and
git-push manpages. So don't duplicate this here in the glossary.
Actually the definition of "pathspec" should be moved to a separate
file akin to the way it's done with "refspec". But this will only be
wortwhile when there's more to say about it. So for the time being
just improve the first sentence a little bit; fix the indentation of
the first paragraph after the bullet list and remove the one-item
list of magic signatures with its - for the user - unnecessary
introduction of "magic word 'top'".
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
glossary: improve description of SHA-1 related topics
The name of the hash function is "SHA-1", not "SHA1".
Also to people who look up "object name" in the glossary,
the details of which hash function is applied on what to
compute "object name" is not important but the fact that the
name is meant to be an unique identifier for the contents
stored in the object is.
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb/INSTALL: Simplify description of GITWEB_CONFIG_SYSTEM
The flow of the text describing GITWEB_CONFIG_SYSTEM and
GITWEB_CONFIG_COMMON in gitweb/INSTALL is awkward. "This is bad. Oh
the other hand, better is broken. Therefore we do this." forces
readers to make multiple guesses while reading: "ok, bad, so you
plan to change it and warn us about upcoming change? oh, not that,
changing it is bad, so we have to live with it? oh, not that, there
is another one that is common and that is what we can use".
Better rewrite said paragraph to avoid such a mental roller-coaster in
the first place.
Signed-off-by: Junio Hamano <gitster@pobox.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The $test variable is used as an interim buffer for
constructing $TRASH_DIRECTORY, and is almost compatible with
it (the exception being that $test has not been converted to
an absolute path). Let's get rid of it entirely so that
later code does not accidentally use it, thinking the two
are interchangeable.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
After the location of $TRASH_DIRECTORY is adjusted by
$TEST_OUTPUT_DIRECTORY, we go on to use the $test variable to make the
trash directory and cd into it. This means that when
$TEST_OUTPUT_DIRECTORY is not "." and an absolute --root has not been
specified, we do not remove the trash directory once the tests are
complete (remove_trash is set to $TRASH_DIRECTORY).
Fix this by always referring to the trash directory as $TRASH_DIRECTORY.
Signed-off-by: John Keeping <john@keeping.me.uk> Acked-by: Jeff King <peff@peff.net> Acked-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
doc/http-backend: match query-string in apache half-auth example
When setting up a "half-auth" repository in which reads can
be done anonymously but writes require authentication, it is
best if the server can require authentication for both the
ref advertisement and the actual receive-pack POSTs. This
alleviates the need for the admin to set http.receivepack in
the repositories, and means that the client is challenged
for credentials immediately, instead of partway through the
push process (and git clients older than v1.7.11.7 had
trouble handling these challenges).
Since detecting a push during the ref advertisement requires
matching the query string, and this is non-trivial to do in
Apache, we have traditionally punted and instructed users to
just protect "/git-receive-pack$". This patch provides the
mod_rewrite recipe to actually match the ref advertisement,
which is preferred.
While we're at it, let's add the recipe to our test scripts
so that we can be sure that it works, and doesn't get broken
(either by our changes or by changes in Apache).
Signed-off-by: Jeff King <peff@peff.net> Acked-by: Jakub Narębski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'rr/send-email-perl-critique' into maint
* rr/send-email-perl-critique:
send-email: use the three-arg form of open in recipients_cmd
send-email: drop misleading function prototype
send-email: use "return;" not "return undef;" on error codepaths
Most of these were found using Lucas De Marchi's codespell tool.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
doc: clarify that "git daemon --user=<user>" option does not export HOME=~user
The fact that we don't set $HOME may confuse admins who expect
~<user>/.gitconfig to be used, because that is not what we try to
read. And worse, since 96b9e0e3, a git-daemon started by root is
likely to fail to run at all, as the user we switch to generally
cannot read ~root.
Signed-off-by: Jeff King <peff@peff.net> Helped-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: distinguish between ref and offset deltas in pack-format
eb32d236 introduced the OBJ_OFS_DELTA object that uses a relative offset to
identify the base object instead of the 20-byte SHA1 reference. The pack file
documentation only mentions the SHA1 based reference in its description of the
deltified object entry.
Update the pack format documentation to clarify that the deltified object
representation refers to its base using either a relative negative offset or
the absolute SHA1 identifier.
Signed-off-by: Stefan Saasen <ssaasen@atlassian.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The advice (consider use of -u when read_directory takes too long) is
separated into 3 different status_printf_ln() calls, and which brings
trouble for translators.
Since status_vprintf() called by status_printf_ln() can handle eol in
buffer, we could simply join these lines into one paragraph.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
archive: clarify explanation of --worktree-attributes
Make it a bit clearer that --worktree-attributes is about files in the
working tree (checked out files, possibly changed) and not the current
working directory ($PWD). Link to the ATTRIBUTES section, which has
more details.
Reported-by: Amit Bakshi <ambakshi@gmail.com> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
doc/http-backend: give some lighttpd config examples
The examples in the documentation are all for Apache. Let's
at least cover the basics: an anonymous server, an
authenticated server, and a "half auth" server with
anonymous read and authenticated write.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the http-backend is set up to allow anonymous read but
authenticated write, the http-backend manual suggests
catching only the "/git-receive-pack" POST of the packfile,
not the initial "info/refs?service=git-receive-pack" GET in
which we advertise refs.
This does work and is secure, as we do not allow any write
during the info/refs request, and the information in the ref
advertisement is the same that you would get from a fetch.
However, the configuration required by the server is
slightly more complex. The default `http.receivepack`
setting is to allow pushes if the webserver tells us that
the user authenticated, and otherwise to return a 403
("Forbidden"). That works fine if authentication is turned
on completely; the initial request requires authentication,
and http-backend realizes it is OK to do a push.
But for this "half-auth" state, no authentication has
occurred during the initial ref advertisement. The
http-backend CGI therefore does not think that pushing
should be enabled, and responds with a 403. The client
cannot continue, even though the server would have allowed
it to run if it had provided credentials.
It would be much better if the server responded with a 401,
asking for credentials during the initial contact. But
git-http-backend does not know about the server's auth
configuration (so a 401 would be confusing in the case of a
true anonymous server). Unfortunately, configuring Apache to
recognize the query string and apply the auth appropriately
to receive-pack (but not upload-pack) initial requests is
non-trivial.
The site admin can work around this by just turning on
http.receivepack explicitly in its repositories. Let's
document this workaround.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5004: fix issue with empty archive test and bsdtar
bsdtar, which is the default tar on Mac OS X, handles empty archives
just fine but reports archives containing only a pax extended header
comment as damaged. Work around the issue by explicitly generating
the archive for the tree and not the commit, which causes git archive
to omit the commit hash comment record from the tar file.
Reported-by: BJ Hargrave <bj@bjhargrave.com> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
bundle: Accept prerequisites without commit messages
While explicitly stating that the commit message in a prerequisite
line is optional, we required all lines with 40 or more characters
to contain a space after the object name, bailing out if a line
consisted of an object name only. This was to allow bundling a
history to a commit without an message, but the code forgot that it
already called rtrim() to remove that whitespace.
As a workaround, only check for SP when the line has more than 40
characters.
Signed-off-by: Lukas Fleischer <git@cryptocrack.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
fmt-merge-msg: use core.commentchar in tag signatures completely
Commit eff80a9 (Allow custom "comment char") introduced a custom
comment character for commit messages but didn't use it completely
in the tag signature part.
This commit fixes that.
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
fmt-merge-msg: respect core.commentchar in people credits
Commit eff80a9 (Allow custom "comment char") introduced a custom
comment character for commit messages but forgot to use it in
people credits which can be a part of a commit message.
With this commit, the custom comment character is also used
in people credits.
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jc/directory-attrs-regression-fix' into maint-1.8.1
A pattern "dir" (without trailing slash) in the attributes file
stopped matching a directory "dir" by mistake with an earlier change
that wanted to allow pattern "dir/" to also match.
* jc/directory-attrs-regression-fix:
t: check that a pattern without trailing slash matches a directory
dir.c::match_pathname(): pay attention to the length of string parameters
dir.c::match_pathname(): adjust patternlen when shifting pattern
dir.c::match_basename(): pay attention to the length of string parameters
attr.c::path_matches(): special case paths that end with a slash
attr.c::path_matches(): the basename is part of the pathname
When we generate relative names (e.g., "master~20^2"), we
format the name into a static buffer, then xstrdup the
result to attach it to the commit. Since the first thing we
add into the static buffer is the already-computed name of
the child commit, the names may get longer and longer as
the traversal gets deeper, and we may eventually overflow
the fixed-size buffer.
Fix this by converting the fixed-size buffer into a dynamic
strbuf. The performance implications should be minimal, as
we end up allocating a heap copy of the name anyway (and now
we can just detach the heap copy from the strbuf).
Reported-by: Eric Roman <eroman@chromium.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff: allow unstuck arguments with --diff-algorithm
The argument to --diff-algorithm is mandatory, so there is no reason to
require the argument to be stuck to the option with '='. Change this
for consistency with other Git commands.
Note that this does not change the handling of diff-algorithm in
merge-recursive.c since the primary interface to that is via the -X
option to 'git merge' where the unstuck form does not make sense.
Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-merge(1): document diff-algorithm option to merge-recursive
Commit 07924d4 (diff: Introduce --diff-algorithm command line option
2013-01-16) added diff-algorithm as a parameter to the recursive merge
strategy but did not document it. Do so.
Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we introduced the concept of "detached HEAD", we made sure that
commands that operate on the history of the current branch "just
work" in that state. They update the HEAD to point at the new
history without affecting any branch when the HEAD is detached, just
like they update the tip of the "current branch" to point at the new
history when HEAD points at a specific branch.
As this is done as the natural extension for these commands, we did
not, we still do not, and we do not want to repeat "A detached HEAD
is updated without affecting any branch" when describing what each
and every one of these commands that operates "on the current branch"
does.
Add a blanket description to the glossary to cover them instead.
The general principle is that operations to update the branch work
on and affect the HEAD, while operations to update the information
about a branch do not.
The logic flow of has_changes() used for "log -S" and diff_grep()
used for "log -G" are essentially the same. See if we have both
sides that could be different in any interesting way, slurp the
contents in core, possibly after applying textconv, inspect the
contents, clean-up and report the result. The only difference
between the two is how "inspect" step works.
Unify this codeflow in a helper, pickaxe_match(), which takes a
callback function that implements the specific "inspect" step.
After removing the common scaffolding code from the existing
has_changes() and diff_grep(), they each becomes such a callback
function suitable for passing to pickaxe_match().
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diffcore-pickaxe: fix leaks in "log -S<block>" and "log -G<pattern>"
The diff_grep() and has_changes() functions had early return
codepaths for unmerged filepairs, which simply returned 0. When we
taught textconv filter to them, one was ignored and continued to
return early without freeing the result filtered by textconv, and
the other had a failed attempt to fix, which allowed the planned
return value 0 to be overwritten by a bogus call to contains().