An earlier commit 15da108 ("send-email: 'References:' should only
reference what is sent", 2009-04-13) broke logic to set up threading
information for the next message by rewriting "!" to "not" without
understanding the precedence rules of the language.
Namely,
! defined $reply_to || length($reply_to) == 0
was changed to
not defined $reply_to || length($reply_to) == 0
which is
not (defined $reply_to || length($reply_to) == 0)
and different from what was intended, which is
(not defined $reply_to) || (length($reply_to) == 0)
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also remove the argument from --[no-]chain-reply-to.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After commit 3e0c4ff (send-email: respect in-reply-to regardless of
threading, 2009-03-01) the variable $thread was only used for prompting
for an "In-Reply-To", but not for controlling whether the "In-Reply-To"
and "References" fields should be written into the email.
Thus these fields were always used beginning with the second mail and it
was not possible to produce non-threaded mails anymore.
However, a later commit 15da108 ("send-email: 'References:' should only
reference what is sent", 2009-04-13) introduced a regression with the
side effect to make non-threaded mails possible again, but only when
--no-chain-reply-to was used.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
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>
Expand get_remote_merge_branch to compute the tracking branch to merge
when called without arguments (or only the remote name). This allows
"git pull --rebase" without arguments (default upstream branch) to
work with a rebased upstream. With explicit arguments it already worked.
Also add a test to check for this case.
Signed-off-by: Santi Béjar <santi@agolina.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The only user of get_remote_refs_for_fetch was "git pull --rebase" and
it only wanted the tracking branch to be merge. So, add a simple
function (get_remote_merge_branch) with this new meaning.
No behavior changes. The new function behaves like the old code in
"git pull --rebase". In particular, it only works with the default
refspec mapping and with remote branches, not tags.
Signed-off-by: Santi Béjar <santi@agolina.net>
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>
It only searches for now for the dreaded LASTARG_DEFAULT | OPTARG
combination, but can be extended to check for any other forbidden
combination.
Options are checked each time we call parse_options_start.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check if -lresolv is needed for hstrerror; set NEEDS_RESOLV
accordingly, and substitute in config.mak.in.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In an earlier patch, we introduced SANE_TOOL_PATH that is prepended to
user's PATH. This had an unintended consequence of overriding user's
private binary directory that typically comes earlier in the PATH to holds
even saner commands than whatever comes with the system.
For example, a user may have ~/bin that is early in the path and contains
a shell script "vi" that launches system's /bin/vi with specific options.
Prepending SANE_TOOL_PATH to the PATH that happens to have "vi" in it
defeats such customization.
This fixes the issue by inserting SANE_TOOL_PATH just before /bin or
/usr/bin appears on the PATH.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Offload object enumeration in upload-pack to pack-objects, but fall
back on internal revision walker for shallow interaction. Aside from
architecturally making more sense, this also leaves the door open for
pack-objects to employ a revision cache mechanism. Test t5530 updated
in order to explicitly check both enumeration methods.
Signed-off-by: Nick Edelen <sirnot@gmail.com>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current text makes some users feel uneasy, worrying whether
'-a' could lead to corrupt repositories. Clarify that '-a'
may lead to performance issues only for dumb protocols.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Helped-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check whether the new remote.${remotename}.pushurl setting is obeyed
and whether it overrides remote.${remotename}.url.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This introduces a config setting remote.$remotename.pushurl which is
used for pushes only. If absent remote.$remotename.url is used for
pushes and fetches as before.
This is useful, for example, in order to do passwordless fetches
(remote update) over the git transport but pushes over ssh.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
diff.c: plug a memory leak in an error path
fetch-pack: close output channel after sideband demultiplexer terminates
builtin-remote: Make "remote show" display all urls
'git stash pop' supports the '--index' option since its initial
implementation (bd56ff54, git-stash: add new 'pop' subcommand,
2008-02-22), but its documentation does not mention it explicitly.
Moreover, both the usage shown by 'git stash -h' and the synopsis
section in the man page imply that 'git stash pop' does not have an
'--index' option.
First, this patch corrects the usage and the synopsis section.
Second, the patch moves the description of the '--index' option to the
'git stash pop' section in the documentation, and refers to it from
the 'git stash apply' section. This way it follows the intentions of
commit d1836637 (Documentation: teach stash/pop workflow instead of
stash/apply, 2009-05-28), as all 'git stash pop'-related documentation
will be in one place without references to 'git stash apply'.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5734365 (show-branch: migrate to parse-options API 2009-05-21)
incorrectly set the --more option's flags to be
PARSE_OPT_LASTARG_DEFAULT and PARSE_OPT_OPTARG. These two flags
shouldn't be used together. An option taking a default should just set
the default value desired and parse options will take care of the rest.
Update the header comment to better convey this information.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rest of the git source has been converted to use upper-case character
encoding names to assist older platforms. The charset attribute of MIME
is defined to be case-insensitive, but older platforms may still have an
easier time dealing with upper-case rather than lower-case. So do so for
send-email too.
Update t9001 to handle the changes.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to rfc2047, an encoded word has the following form:
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
charset = token
encoding = token
token = <Any CHAR except SPACE, CTLs, and especials>
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
<"> / "/" / "[" / "]" / "?" / "." / "="
encoded-text = <Any printable ASCII character other than "?"
or SPACE>
And rfc822 defines CHARs and CTLs as:
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
The original code only detected rfc2047 encoded strings when the charset
was UTF-8. This patch generalizes the matching expression and breaks the
check for an rfc2047 encoded string into its own function. There's no real
functional change, since any properly rfc2047 encoded string would have
fallen through the remaining 'if' statements and been returned unchanged.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
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>
The Sun c99 compiler as recent as version 5.8 Patch 121016-06 2007/08/01
produces an error when compiling diff-delta.c. This source file #includes
the delta.h header file which pre-declares a struct which is later defined
to contain a flex array member. The Sun c99 compiler fails to compile
diff-delta.c and gives the following error:
"diff-delta.c", line 314: identifier redeclared: create_delta
current : function(pointer to const struct delta_index {unsigned long memsize, pointer to const void src_buf, unsigned long src_size, unsigned int hash_mask, array[-1] of pointer to struct index_entry {..} hash}, pointer to const void, unsigned long, pointer to unsigned long, unsigned long) returning pointer to void
previous: function(pointer to const struct delta_index {unsigned long memsize, pointer to const void src_buf, unsigned long src_size, unsigned int hash_mask, array[-1] of pointer to struct index_entry {..} hash}, pointer to const void, unsigned long, pointer to unsigned long, unsigned long) returning pointer to void : "delta.h", line 44
c99: acomp failed for diff-delta.c
So, avoid using this c99 feature when compiling with the Sun c compilers
version 5.8 and older (the most recent version tested).
Signed-off-by: Brandon Casey <drafnel@gmail.com>
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>
This commit changes handling of the msysgit specific settings, so
that they can be applied to official git.git. Some msysgit
settings differ from the standard MinGW settings. We move them
into an ifndef block that is only evaluated if a file
THIS_IS_MSYSGIT is present in the parent directory, which is the
case for an msysgit working environment. The tag file is unlikely
to be present accidentally.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nedmalloc's source code has a cute #define construct to avoid inserting
an if() statement, because that might interact badly with enclosing if()
statements. However, GCC > 4 complains with a "warning: value computed
is not used". So we cast the result to "void".
GCC also does not understand the Visual C++ specific pragmas, so we need
to disable them for MinGW.
We need to include malloc.h on Windows even if we happen to compile the
stuff as a MinGW program. Otherwise the function declaration of alloca()
is missing.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add {}-braces around an else-part, where the if-part already has
{}-braces.
And, also remove some unnecessary "return;"-statements at the end of
"void foo()"-functions.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
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>
Simplify the argh printing by simply calling usage_argh() if the option
can take an argument. Update macros defined in parse-options.h to set
the PARSE_OPT_NOARG flag.
The only other user of custom non-argument taking options is git-apply
(in this case OPTION_BOOLEAN for deprecated options). Update it to set
the PARSE_OPT_NOARG flag.
Thanks to Ren辿 Scharfe for the suggestion and starter patch.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Reviewd-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
OPTION_INTEGER hardcodes its argh member to be "n", but the decision is
hidden deep in usage_with_options_internal(). Make "n" the default argh
for the OPT_INTEGER macro while leaving it undecided for the OPTION_INTEGER
enum.
This makes it less surprising to users that argh is "n" when using the
OPT_INTEGER macro.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Reviewed-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some platforms (like SunOS and family) have kept their common binaries at
some historical moment in time, and introduced new binaries with modern
features in a special location like /usr/xpg4/bin or /usr/ucb. Some of the
features provided by these modern binaries are expected and required by git.
If the featureful binaries are not in the users path, then git could end up
using the less featureful binary and fail.
So provide a mechanism to prepend elements to the users PATH at runtime so
the modern binaries will be found.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The SUNWspro compiler does not define __sun__ (like GCC does). A check of
this macro was recently added to detect compilation on SunOS and to modify
the handling of the NO_ICONV and _XOPEN_SOURCE feature macros.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Solaris, when _XOPEN_EXTENDED is set, its header file forces the
programs to be XPG4v2, defeating any _XOPEN_SOURCE setting to say we are
XPG5 or XPG6. Also on Solaris, XPG6 programs must be compiled with a c99
compiler, while non XPG6 programs must be compiled with a pre-c99 compiler.
So when compiling on Solaris, always refrain from setting _XOPEN_EXTENDED,
and then set _XOPEN_SOURCE to 600 or 500 based on whether a c99 compiler
is being used or not.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
OLD_ICONV is only necessary on Solaris until UNIX03. This is indicated
by the private macro _XPG6 which is set in /usr/include/sys/feature_tests.h.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
