remove unnecessary parameter from get_patch_ids()

get_patch_ids() takes an already initialized rev_info and a
prefix. The prefix is used when initalizing a second rev_info. Since
the initialized rev_info already has a prefix and the prefix never
changes, we can use the prefix from the initialized rev_info to
initialize the second rev_info.

Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cherry: don't set ignored rev_info options

Ever since cherry was built-in in e827633 (Built-in cherry,
2006-10-24), it has set a bunch of options on the the rev_info that
are only used while outputting a patch. But since the built-in cherry
command never needs to output any patch (it uses add_commit_patch_id
and has_commit_patch_id instead), these options are just distractions,
so remove them.

Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cherry: remove redundant check for merge commit

While walking the revision list in get_patch_ids and cmd_cherry, we
check for each commit if there is more than one parent and ignore
the commit if that is the case. Instead, set rev_info.max_parents to
1 and let the revision traversal code handle it for us.

Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
include agent identifier in capability string

Instead of having the client advertise a particular version
number in the git protocol, we have managed extensions and
backwards compatibility by having clients and servers
advertise capabilities that they support. This is far more
robust than having each side consult a table of
known versions, and provides sufficient information for the
protocol interaction to complete.

However, it does not allow servers to keep statistics on
which client versions are being used. This information is
not necessary to complete the network request (the
capabilities provide enough information for that), but it
may be helpful to conduct a general survey of client
versions in use.

We already send the client version in the user-agent header
for http requests; adding it here allows us to gather
similar statistics for non-http requests.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
prune.c: only print informational message in show_only or verbose mode

"git prune" reports removal of loose object files that are no longer
necessary only under the "-v" option, but unconditionally reports
removal of temporary files that are no longer needed.

The original thinking was that the presence of a leftover temporary
file should be an unusual occurrence that may indicate an earlier
failure of some sort, and the user may want to be reminded of it.
Removing an unnecessary loose object file, on the other hand, is
just part of the normal operation.  That is why the former is always
printed out and the latter only when -v is used.

But neither report is particularly useful.  Hide both of these
behind the "-v" option for consistency.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sh-setup: protect from exported IFS

Many scripted Porcelains rely on being able to split words at the
default $IFS characters, i.e. SP, HT and LF.  If the user exports a
non-default IFS to the environment, what they read from plumbing
commands such as ls-files that use HT to delimit fields may not be
split in the way we expect.

Protect outselves by resetting it, just like we do so against CDPATH
exported to the environment.

Noticed by Andrew Dranse <adranse@oanda.com>.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
add tests for 'git rebase --keep-empty'

Add test cases for 'git rebase --keep-empty' with and without an
"empty" commit already in upstream. The empty commit that is about to
be rebased should be kept in both cases.

Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase -i: use full onto sha1 in reflog

'git rebase' uses the full onto sha1 for the reflog message whereas 'git
rebase -i' uses the short sha1. This is not only inconsistent, but can
lead to problems when the reflog is inspected at a later time at which
that abbreviation may have become ambiguous.

Make 'rebase -i' use the full onto sha1, as well.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-pack: fix capability-sending logic

If we have capabilities to send to the server, we send the
regular "want" line followed by a NUL, then the
capabilities; otherwise, we do not even send the NUL.

However, when checking whether we want to send the "quiet"
capability, we check args->quiet, which is wrong. That flag
only tells us whether the client side wanted to be quiet,
not whether the server supports it (originally, in c207e34f,
it meant both; however, that was later split into two flags
by 01fdc21f).

We still check the right flag when actually printing
"quiet", so this could only have two effects:

  1. We might send the trailing NUL when we do not otherwise
     need to. In theory, an antique pre-capability
     implementation of git might choke on this (since the
     client is instructed never to respond with capabilities
     that the server has not first advertised).

  2. We might also want to send the quiet flag if the
     args->progress flag is false, but this code path would
     not trigger in that instance.

In practice, it almost certainly never matters. The
report-status capability dates back to 2005. Any real-world
server is going to advertise that, and we will always
respond with at least that capability.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
do not send client agent unless server does first

Commit ff5effdf taught both clients and servers of the git protocol
to send an "agent" capability that just advertises their version for
statistics and debugging purposes.  The protocol-capabilities.txt
document however indicates that the client's advertisement is
actually a response, and should never include capabilities not
mentioned in the server's advertisement.

Adding the unconditional advertisement in the server programs was
OK, then, but the clients broke the protocol.  The server
implementation of git-core itself does not care, but at least one
does: the Google Code git server (or any server using Dulwich), will
hang up with an internal error upon seeing an unknown capability.

Instead, each client must record whether we saw an agent string from
the server, and respond with its agent only if the server mentioned
it first.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch-pack: do not ask for unadvertised capabilities

In the same spirit as the previous fix, stop asking for thin-pack, no-progress
and include-tag capabilities when the other end does not claim to support them.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
parse_feature_request: make it easier to see feature values

We already take care to parse key/value capabilities like
"foo=bar", but the code does not provide a good way of
actually finding out what is on the right-hand side of the
"=".

A server using "parse_feature_request" could accomplish this
with some extra parsing. You must skip past the "key"
portion manually, check for "=" versus NUL or space, and
then find the length by searching for the next space (or
NUL).  But clients can't even do that, since the
"server_supports" interface does not even return the
pointer.

Instead, let's have our parser share more information by
providing a pointer to the value and its length. The
"parse_feature_value" function returns a pointer to the
feature's value portion, along with the length of the value.
If the feature is missing, NULL is returned. If it does not
have an "=", then a zero-length value is returned.

Similarly, "server_feature_value" behaves in the same way,
but always checks the static server_feature_list variable.

We can then implement "server_supports" in terms of
"server_feature_value". We cannot implement the original
"parse_feature_request" in terms of our new function,
because it returned a pointer to the beginning of the
feature. However, no callers actually cared about the value
of the returned pointer, so we can simplify it to a boolean
just as we do for "server_supports".

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch-pack: mention server version with verbose output

Fetch-pack's verbose mode is more of a debugging mode (and
in fact takes two "-v" arguments to trigger via the
porcelain layer). Let's mention the server version as
another possible item of interest.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Let submodule command exit with error status if path does not exist

Various subcommands of the "git submodule" command exited with 0
status even though the path given by the user did not exist.

The reason behind that was that they all pipe the output of
module_list into the while loop which then does the action on the
paths specified by the commandline. Since the exit code of the
command on the upstream side of the pipe is ignored by the shell,
the status code of "ls-files --error-unmatch" nor "module_list" was
not propagated.

In case ls-files returns with an error code, we write a special
string that is not possible in non error situations, and no other
output, so that the downstream can detect the error and die with an
error code.

The error message that there is an unmatched pathspec comes through
stderr directly from ls-files. So the user still gets a hint whats going
on.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
contrib: add win32 credential-helper

Since the Windows port of Git expects binary pipes, we need to make
sure the helper-end also sets up binary pipes.

Side-step CRLF-issue in test to make it pass.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cleanup precompose_utf8

 - Remove extraneous parentheses and braces;

 - Remove redundant NUL-termination before strcpy();

 - Check result of unlink when probing for decomposed file names;

 - Adjust for the coding style by adding missing whitespaces;

 - Move storage class "static" at the beginning of the decl.

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-config.txt: fix example

The "--add" option is required to add a new value to a multivalued
configuration entry.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-config doc: unconfuse an example

One fictitious command "proxy-command" is enclosed inside a double
quote pair, while another fictitious command "default-proxy" is not
in the example, but the quoting does not change anything in the pair
of examples.  Remove the quotes to avoid unnecessary confusion.

Noticed by Michael Haggerty.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
precompose-utf8: do not call checks for non-ascii "utf8"

As suggested by Linus, this function is not checking UTF-8-ness of the
string; it only is seeing if it is pure US-ASCII.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'mz/cherry-code-cleanup'

Minor code clean-up on the cherry-pick codepath.

* mz/cherry-code-cleanup:
  cherry: remove redundant check for merge commit
  cherry: don't set ignored rev_info options
  remove unnecessary parameter from get_patch_ids()