tokkee.org

Convert resolve_ref+xstrdup to new resolve_refdup function

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update documentation for stripspace

Tell the user what this command is intended for, and expand the
description of what it does.

Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

contrib: add credential helper for OS X Keychain

With this installed in your $PATH, you can store
git-over-http passwords in your keychain by doing:

  git config credential.helper osxkeychain

The code is based in large part on the work of Jay Soffian,
who wrote the helper originally for the initial, unpublished
version of the credential helper protocol.

This version will pass t0303 if you do:

  GIT_TEST_CREDENTIAL_HELPER=osxkeychain \
  GIT_TEST_CREDENTIAL_HELPER_SETUP="export HOME=$HOME" \
  ./t0303-credential-external.sh

The "HOME" setup is unfortunately necessary. The test
scripts set HOME to the trash directory, but this causes the
keychain API to complain.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: OS X has /dev/tty

We can use our enhanced getpass(). Tested by me.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: linux has /dev/tty

Therefore we can turn on our custom prompt function instead
of relying on getpass.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

credential: use git_prompt instead of git_getpass

We use git_getpass to retrieve the username and password
from the terminal. However, git_getpass will not echo the
username as the user types. We can fix this by using the
more generic git_prompt, which underlies git_getpass but
lets us specify an "echo" option.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t: add test harness for external credential helpers

We already have tests for the internal helpers, but it's
nice to give authors of external tools an easy way to
sanity-check their helpers.

If you have written the "git-credential-foo" helper, you can
do so with:

  GIT_TEST_CREDENTIAL_HELPER=foo \
  make t0303-credential-external.sh

This assumes that your helper is capable of both storing and
retrieving credentials (some helpers may be read-only, and
they will fail these tests).

If your helper supports time-based expiration with a
configurable timeout, you can test that feature like this:

  GIT_TEST_CREDENTIAL_HELPER_TIMEOUT="foo --timeout=1" \
  make t0303-credential-external.sh

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

prompt: use git_terminal_prompt

Our custom implementation of git_terminal_prompt has many
advantages over regular getpass(), as described in the prior
commit.

This also lets us implement a PROMPT_ECHO flag for callers
who want it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

credentials: add "store" helper

This is like "cache", except that we actually put the
credentials on disk. This can be terribly insecure, of
course, but we do what we can to protect them by filesystem
permissions, and we warn the user in the documentation.

This is not unlike using .netrc to store entries, but it's a
little more user-friendly. Instead of putting credentials in
place ahead of time, we transparently store them after
prompting the user for them once.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add generic terminal prompt function

When we need to prompt the user for input interactively, we
want to access their terminal directly. We can't rely on
stdio because it may be connected to pipes or files, rather
than the terminal. Instead, we use "getpass()", because it
abstracts the idea of prompting and reading from the
terminal.  However, it has some problems:

  1. It never echoes the typed characters, which makes it OK
     for passwords but annoying for other input (like usernames).

  2. Some implementations of getpass() have an extremely
     small input buffer (e.g., Solaris 8 is reported to
     support only 8 characters).

  3. Some implementations of getpass() will fall back to
     reading from stdin (e.g., glibc). We explicitly don't
     want this, because our stdin may be connected to a pipe
     speaking a particular protocol, and reading will
     disrupt the protocol flow (e.g., the remote-curl
     helper).

  4. Some implementations of getpass() turn off signals, so
     that hitting "^C" on the terminal does not break out of
     the password prompt. This can be a mild annoyance.

Instead, let's provide an abstract "git_terminal_prompt"
function that addresses these concerns. This patch includes
an implementation based on /dev/tty, enabled by setting
HAVE_DEV_TTY. The fallback is to use getpass() as before.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

refactor git_getpass into generic prompt function

This will allow callers to specify more options (e.g.,
leaving echo on). The original git_getpass becomes a slim
wrapper around the new function.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

move git_getpass to its own source file

This is currently in connect.c, but really has nothing to
do with the git protocol itself. Let's make a new source
file all about prompting the user, which will make it
cleaner to refactor.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

imap-send: don't check return value of git_getpass

git_getpass will always die() if we weren't able to get
input, so there's no point looking for NULL.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

imap-send: avoid buffer overflow

We format the password prompt in an 80-character static
buffer. It contains the remote host and username, so it's
unlikely to overflow (or be exploitable by a remote
attacker), but there's no reason not to be careful and use
a strbuf.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

strbuf: add strbuf_add*_urlencode

This just follows the rfc3986 rules for percent-encoding
url data into a strbuf.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: unix sockets may not available on some platforms

Introduce a configuration option NO_UNIX_SOCKETS to exclude code that
depends on Unix sockets and use it in MSVC and MinGW builds.

Notice that unix-socket.h was missing from LIB_H before; fix that, too.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

grep: load funcname patterns for -W

git-grep avoids loading the funcname patterns unless they are needed.
ba8ea74 (grep: add option to show whole function as context,
2011-08-01) forgot to extend this test also to the new funcbody
feature.  Do so.

The catch is that we also have to disable threading when using
userdiff, as explained in grep_threads_ok().  So we must be careful to
introduce the same test there.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mv: be quiet about overwriting

When a user asks us to force a mv and overwrite the
destination, we print a warning. However, since a typical
use would be:

  $ git mv one two
  fatal: destination exists, source=one, destination=two
  $ git mv -f one two
  warning: overwriting 'two'

this warning is just noise. We already know we're
overwriting; that's why we gave -f!

This patch silences the warning unless "--verbose" is given.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mv: improve overwrite warning

When we try to "git mv" over an existing file, the error
message is fairly informative:

  $ git mv one two
  fatal: destination exists, source=one, destination=two

When the user forces the overwrite, we give a warning:

  $ git mv -f one two
  warning: destination exists; will overwrite!

This is less informative, but still sufficient in the simple
rename case, as there is only one rename happening.

But when moving files from one directory to another, it
becomes useless:

  $ mkdir three
  $ touch one two three/one
  $ git add .
  $ git mv one two three
  fatal: destination exists, source=one, destination=three/one
  $ git mv -f one two three
  warning: destination exists; will overwrite!

The first message is helpful, but the second one gives us no
clue about what was overwritten. Let's mention the name of
the destination file:

  $ git mv -f one two three
  warning: overwriting 'three/one'

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revert: stop creating and removing sequencer-old directory

Now that "git reset" no longer implicitly removes .git/sequencer that
the operator may or may not have wanted to keep, the logic to write a
backup copy of .git/sequencer and remove it when stale is not needed
any more.  Simplify the sequencer API and repository layout by
dropping it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Revert "reset: Make reset remove the sequencer state"

This reverts commit 95eb88d8ee588d89b4f06d2753ed4d16ab13b39f, which
was a UI experiment that did not reflect how "git reset" actually gets
used.  The reversion also fixes a test, indicated in the patch.

Encouraged-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revert: do not remove state until sequence is finished

As v1.7.8-rc0~141^2~4 (2011-08-04) explains, git cherry-pick removes
the sequencer state just before applying the final patch.  In the
single-pick case, that was a good thing, since --abort and --continue
work fine without access to such state and removing it provides a
signal that git should not complain about the need to clobber it ("a
cherry-pick or revert is already in progress") in sequences like the
following:

git cherry-pick foo
git read-tree -m -u HEAD; # forget that; let's try a different one
git cherry-pick bar

After the recent patch "allow single-pick in the middle of cherry-pick
sequence" we don't need that hack any more.  In the new regime, a
traditional "git cherry-pick <commit>" command never looks at
.git/sequencer, so we do not need to cripple "git cherry-pick
<commit>..<commit>" for it any more.

So now you can run "git cherry-pick --abort" near the end of a
multi-pick sequence and it will abort the entire sequence, instead of
misbehaving and aborting just the final commit.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revert: allow single-pick in the middle of cherry-pick sequence

After messing up a difficult conflict resolution in the middle of a
cherry-pick sequence, it can be useful to be able to

git checkout HEAD . && git cherry-pick that-one-commit

to restart the conflict resolution. The current code however errors out
saying that another cherry-pick is already in progress.

Suggested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revert: pass around rev-list args in already-parsed form

Since 7e2bfd3f (revert: allow cherry-picking more than one commit,
2010-07-02), the pick/revert machinery has kept track of the set of
commits to be cherry-picked or reverted using commit_argc and
commit_argv variables, storing the corresponding command-line
parameters.

Future callers as other commands are built in (am, rebase, sequencer)
may find it easier to pass rev-list options to this machinery in
already-parsed form.  Teach cmd_cherry_pick and cmd_revert to parse
the rev-list arguments in advance and pass the commit set to
pick_revisions() as a rev_info structure.

Original patch by Jonathan, tweaks and test from Ram.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revert: allow cherry-pick --continue to commit before resuming

When "git cherry-pick ..bar" encounters conflicts, permit the operator
to use cherry-pick --continue after resolving them as a shortcut for
"git commit && git cherry-pick --continue" to record the resolution
and carry on with the rest of the sequence.

This improves the analogy with "git rebase" (in olden days --continue
was the way to preserve authorship when a rebase encountered
conflicts) and fits well with a general UI goal of making "git cmd
--continue" save humans the trouble of deciding what to do next.

Example: after encountering a conflict from running "git cherry-pick
foo bar baz":

CONFLICT (content): Merge conflict in main.c
error: could not apply f78a8d98c... bar!
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

We edit main.c to resolve the conflict, mark it acceptable with "git
add main.c", and can run "cherry-pick --continue" to resume the
sequence.

$ git cherry-pick --continue
[editor opens to confirm commit message]
[master 78c8a8c98] bar!
 1 files changed, 1 insertions(+), 1 deletions(-)
[master 87ca8798c] baz!
 1 files changed, 1 insertions(+), 1 deletions(-)

This is done for both codepaths to pick multiple commits and a single
commit.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revert: give --continue handling its own function

This makes pick_revisions() a little shorter and easier to read
straight through.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mv: make non-directory destination error more clear

If you try to "git mv" multiple files onto another
non-directory file, you confusingly get the "usage" message:

  $ touch one two three
  $ git add .
  $ git mv one two three
  usage: git mv [options] <source>... <destination>
  [...]

From the user's perspective, that makes no sense. They just
gave parameters that exactly match that usage!

This behavior dates back to the original C version of "git
mv", which had a usage message like:

  usage: git mv (<source> <destination> | <source>...  <destination>)

This was slightly less confusing, because it at least
mentions that there are two ways to invoke (but it still
isn't clear why what the user provided doesn't work).

Instead, let's show an error message like:

  $ git mv one two three
  fatal: destination 'three' is not a directory

We could leave the usage message in place, too, but it
doesn't actually help here. It contains no hints that there
are two forms, nor that multi-file form requires that the
endpoint be a directory. So it just becomes useless noise
that distracts from the real error.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mv: honor --verbose flag

The code for a verbose flag has been here since "git mv" was
converted to C many years ago, but actually getting the "-v"
flag from the command line was accidentally lost in the
transition.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

docs: mention "-k" for both forms of "git mv"

The "git mv" synopsis shows two forms: renaming a file, and
moving files into a directory. They can both make use of the
"-k" flag to ignore errors, so mention it in both places.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revert: convert resolve_ref() to read_ref_full()

This is the follow up of c689332 (Convert many resolve_ref() calls to
read_ref*() and ref_exists() - 2011-11-13). See the said commit for
rationale.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

compat/snprintf: don't look at va_list twice

If you define SNPRINTF_RETURNS_BOGUS, we use a special
git_vsnprintf wrapper assumes that vsnprintf returns "-1"
instead of the number of characters that you would need to
store the result.

To do this, it invokes vsnprintf multiple times, growing a
heap buffer until we have enough space to hold the result.
However, this means we evaluate the va_list parameter
multiple times, which is generally a bad thing (it may be
modified by calls to vsnprintf, yielding undefined
behavior).

Instead, we must va_copy it and hand the copy to vsnprintf,
so we always have a pristine va_list.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add_ref(): take a (struct ref_entry *) parameter

Take a pointer to the ref_entry to add to the array, rather than
creating the ref_entry within the function.  This opens the way to
having multiple kinds of ref_entries.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

create_ref_entry(): extract function from add_ref()

Separate the creation of the ref_entry from its addition to a ref_array.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

repack_without_ref(): remove temporary

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

resolve_gitlink_ref_recursive(): change to work with struct ref_cache

resolve_gitlink_ref() and resolve_gitlink_ref_recursive(), together,
basically duplicated the code in git_path_submodule().  So use that
function instead.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Pass a (ref_cache *) to the resolve_gitlink_*() helper functions

And remove some redundant arguments from resolve_gitlink_packed_ref().

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

resolve_gitlink_ref(): improve docstring

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

get_ref_dir(): change signature

Change get_ref_dir() to take a (struct ref_cache *) in place of the
submodule name.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

refs: change signatures of get_packed_refs() and get_loose_refs()

Change get_packed_refs() and get_loose_refs() to take a (struct
ref_cache *) instead of the name of the submodule.

Change get_ref_dir() to take a submodule name (i.e., "" for the main
module) rather than a submodule pointer (i.e., NULL for the main
module) so that refs->name can be used as its argument.  (In a moment
this function will also be changed to take a (struct ref_cache *),
too.)

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

is_dup_ref(): extract function from sort_ref_array()

Giving the function a name makes the code easier to understand.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add_ref(): add docstring

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

parse_ref_line(): add docstring

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

is_refname_available(): remove the "quiet" argument

quiet was always set to 0, so get rid of it.  Add a function docstring
for good measure.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

clear_ref_array(): rename from free_ref_array()

Rename the function since it doesn't actually free the array object
that is passed to it.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

refs: rename parameters result -> sha1

Try consistently to use the name "sha1" for parameters to which a SHA1
will be stored.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

refs: rename "refname" variables

Try to consistently use the variable name "refname" when referring to
a string that names a reference.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

struct ref_entry: document name member

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

credentials: add "cache" helper

If you access repositories over smart-http using http
authentication, then it can be annoying to have git ask you
for your password repeatedly. We cache credentials in
memory, of course, but git is composed of many small
programs. Having to input your password for each one can be
frustrating.

This patch introduces a credential helper that will cache
passwords in memory for a short period of time.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

docs: end-user documentation for the credential subsystem

The credential API and helper format is already defined in
technical/api-credentials.txt.  This presents the end-user
view.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

credential: make relevance of http path configurable

When parsing a URL into a credential struct, we carefully
record each part of the URL, including the path on the
remote host, and use the result as part of the credential
context.

This had two practical implications:

  1. Credential helpers which store a credential for later
     access are likely to use the "path" portion as part of
     the storage key. That means that a request to

       https://example.com/foo.git

     would not use the same credential that was stored in an
     earlier request for:

       https://example.com/bar.git

  2. The prompt shown to the user includes all relevant
     context, including the path.

In most cases, however, users will have a single password
per host. The behavior in (1) will be inconvenient, and the
prompt in (2) will be overly long.

This patch introduces a config option to toggle the
relevance of http paths. When turned on, we use the path as
before. When turned off, we drop the path component from the
context: helpers don't see it, and it does not appear in the
prompt.

This is nothing you couldn't do with a clever credential
helper at the start of your stack, like:

  [credential "http://"]
helper = "!f() { grep -v ^path= ; }; f"
helper = your_real_helper

But doing this:

  [credential]
useHttpPath = false

is way easier and more readable. Furthermore, since most
users will want the "off" behavior, that is the new default.
Users who want it "on" can set the variable (either for all
credentials, or just for a subset using
credential.*.useHttpPath).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

credential: add credential.*.username

Credential helpers can help users avoid having to type their
username and password over and over. However, some users may
not want a helper for their password, or they may be running
a helper which caches for a short time. In this case, it is
convenient to provide the non-secret username portion of
their credential via config.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

credential: apply helper config

The functionality for credential storage helpers is already
there; we just need to give the users a way to turn it on.
This patch provides a "credential.helper" configuration
variable which allows the user to provide one or more helper
strings.

Rather than simply matching credential.helper, we will also
compare URLs in subsection headings to the current context.
This means you can apply configuration to a subset of
credentials. For example:

  [credential "https://example.com"]
helper = foo

would match a request for "https://example.com/foo.git", but
not one for "https://kernel.org/foo.git".

This is overkill for the "helper" variable, since users are
unlikely to want different helpers for different sites (and
since helpers run arbitrary code, they could do the matching
themselves anyway).

However, future patches will add new config variables where
this extra feature will be more useful.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

http: use credential API to get passwords

This patch converts the http code to use the new credential
API, both for http authentication as well as for getting
certificate passwords.

Most of the code change is simply variable naming (the
passwords are now contained inside the credential struct)
or deletion of obsolete code (the credential code handles
URL parsing and prompting for us).

The behavior should be the same, with one exception: the
credential code will prompt with a description based on the
credential components. Therefore, the old prompt of:

  Username for 'example.com':
  Password for 'example.com':

now looks like:

  Username for 'https://example.com/repo.git':
  Password for 'https://user@example.com/repo.git':

Note that we include more information in each line,
specifically:

  1. We now include the protocol. While more noisy, this is
     an important part of knowing what you are accessing
     (especially if you care about http vs https).

  2. We include the username in the password prompt. This is
     not a big deal when you have just been prompted for it,
     but the username may also come from the remote's URL
     (and after future patches, from configuration or
     credential helpers).  In that case, it's a nice
     reminder of the user for which you're giving the
     password.

  3. We include the path component of the URL. In many
     cases, the user won't care about this and it's simply
     noise (i.e., they'll use the same credential for a
     whole site). However, that is part of a larger
     question, which is whether path components should be
     part of credential context, both for prompting and for
     lookup by storage helpers. That issue will be addressed
     as a whole in a future patch.

Similarly, for unlocking certificates, we used to say:

  Certificate Password for 'example.com':

and we now say:

  Password for 'cert:///path/to/certificate':

Showing the path to the client certificate makes more sense,
as that is what you are unlocking, not "example.com".

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

credential: add function for parsing url components

All of the components of a credential struct can be found in
a URL.  For example, the URL:

  http://foo:bar@example.com/repo.git

contains:

  protocol=http
  host=example.com
  path=repo.git
  username=foo
  password=bar

We want to be able to turn URLs into broken-down credential
structs so that we know two things:

  1. Which parts of the username/password we still need

  2. What the context of the request is (for prompting or
     as a key for storing credentials).

This code is based on http_auth_init in http.c, but needed a
few modifications in order to get all of the components that
the credential object is interested in.

Once the http code is switched over to the credential API,
then http_auth_init can just go away.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

introduce credentials API

There are a few places in git that need to get a username
and password credential from the user; the most notable one
is HTTP authentication for smart-http pushing.

Right now the only choices for providing credentials are to
put them plaintext into your ~/.netrc, or to have git prompt
you (either on the terminal or via an askpass program). The
former is not very secure, and the latter is not very
convenient.

Unfortunately, there is no "always best" solution for
password management. The details will depend on the tradeoff
you want between security and convenience, as well as how
git can integrate with other security systems (e.g., many
operating systems provide a keychain or password wallet for
single sign-on).

This patch provides an abstract notion of credentials as a
data item, and provides three basic operations:

  - fill (i.e., acquire from external storage or from the
    user)

  - approve (mark a credential as "working" for further
    storage)

  - reject (mark a credential as "not working", so it can
    be removed from storage)

These operations can be backed by external helper processes
that interact with system- or user-specific secure storage.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5550: fix typo

This didn't have an impact, because it was just setting up
an "expect" file that happened to be identical to the one in
the test before it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test-lib: add test_config_global variant

The point of test_config is to simultaneously set a config
variable and register its cleanup handler, like:

  test_config core.foo bar

However, it stupidly assumes that $1 contained the name of
the variable, which means it won't work for:

  test_config --global core.foo bar

We could try to parse the command-line ourselves and figure
out which parts need to be fed to test_unconfig. But since
this is likely the most common variant, it's much simpler
and less error-prone to simply add a new function.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Test 'checkout -m -- path'

Signed-off-by: Pete Harlan <pgit@pcharlan.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3401: use test_commit in setup

Simplify t3401 by using test_commit in the setup. This lets us refer
to commits using their tags and there is no longer a need to create
the branch my-topic-branch-merge. Also, the branch master-merge points
to the same commit as master (even before this change), so that branch
does not need to be created either.

While at it, replace "test ! -d" by "test_path_is_missing".

Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3401: modernize style

Put the opening quote starting each test on the same line as the
test_expect_* invocation. Also make sure to use tabs for indentation.

Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: test for absolute PWD problem

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: use absolute directory for PWD env var

P4 only looks at the environment variable $PWD to figure out
where it is, so chdir() has code to set that every time.  But
when the clone --destination is not an absolute path, PWD will
not be absolute and P4 won't be able to find any files expected
to be in the current directory.  Fix this by expanding PWD to
an absolute path.

One place this crops up is when using a P4CONFIG environment
variable to specify P4 parameters, such as P4USER or P4PORT.
Setting P4CONFIG=.p4config works for p4 invocations from the
current directory.  But if the value of PWD is not absolute, it
fails.

[ update description --pw ]

Signed-off-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: submit test for auto-creating clientPath

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: ensure submit clientPath exists before chdir

Submitting patches back to p4 requires a p4 "client".  This
is a mapping from server depot paths into a local directory.
The directory need not exist or be populated with files; only
the mapping on the server is required.  When there is no
directory, make git-p4 automatically create it.

[ reword description --pw ]

Signed-off-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: create status table using strbuf

When we fetch from a remote, we print a status table like:

  From url
   * [new branch]   foo -> origin/foo

We create this table in a static buffer using sprintf. If
the remote refnames are long, they can overflow this buffer
and smash the stack.

Instead, let's use a strbuf to build the string.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update draft release notes for 1.7.9

The first two of more important topics slated for 1.7.9 have been merged.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'sg/complete-refs'

* sg/complete-refs:
  completion: remove broken dead code from __git_heads() and __git_tags()
  completion: fast initial completion for config 'remote.*.fetch' value
  completion: improve ls-remote output filtering in __git_refs_remotes()
  completion: query only refs/heads/ in __git_refs_remotes()
  completion: support full refs from remote repositories
  completion: improve ls-remote output filtering in __git_refs()
  completion: make refs completion consistent for local and remote repos
  completion: optimize refs completion
  completion: document __gitcomp()

Conflicts:
contrib/completion/git-completion.bash

Merge branch 'nd/resolve-ref'

* nd/resolve-ref:
  Copy resolve_ref() return value for longer use
  Convert many resolve_ref() calls to read_ref*() and ref_exists()

Conflicts:
builtin/fmt-merge-msg.c
builtin/merge.c
refs.c

Merge branch 'jc/pull-signed-tag'

* jc/pull-signed-tag:
  commit-tree: teach -m/-F options to read logs from elsewhere
  commit-tree: update the command line parsing
  commit: teach --amend to carry forward extra headers
  merge: force edit and no-ff mode when merging a tag object
  commit: copy merged signed tags to headers of merge commit
  merge: record tag objects without peeling in MERGE_HEAD
  merge: make usage of commit->util more extensible
  fmt-merge-msg: Add contents of merged tag in the merge message
  fmt-merge-msg: package options into a structure
  fmt-merge-msg: avoid early returns
  refs DWIMmery: use the same rule for both "git fetch" and others
  fetch: allow "git fetch $there v1.0" to fetch a tag
  merge: notice local merging of tags and keep it unwrapped
  fetch: do not store peeled tag object names in FETCH_HEAD
  Split GPG interface into its own helper library

Conflicts:
builtin/fmt-merge-msg.c
builtin/merge.c

Merge branch 'jc/request-pull-show-head-4'

* jc/request-pull-show-head-4:
  request-pull: use the annotated tag contents
  fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
  environment.c: Fix an sparse "symbol not declared" warning
  builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
  fmt-merge-msg: use branch.$name.description
  request-pull: use the branch description
  request-pull: state what commit to expect
  request-pull: modernize style
  branch: teach --edit-description option
  format-patch: use branch description in cover letter
  branch: add read_branch_desc() helper function

Conflicts:
builtin/branch.c

Merge branch 'ab/pull-rebase-config'

* ab/pull-rebase-config:
  pull: introduce a pull.rebase option to enable --rebase

Merge branch 'rs/allocate-cache-entry-individually'

* rs/allocate-cache-entry-individually:
  cache.h: put single NUL at end of struct cache_entry
  read-cache.c: allocate index entries individually

Conflicts:
read-cache.c

Merge branch 'maint'

* maint:
  am: don't persist keepcr flag
  mingw: give waitpid the correct signature
  git symbolic-ref: documentation fix

Merge branch 'maint-1.7.7' into maint

* maint-1.7.7:
  am: don't persist keepcr flag
  mingw: give waitpid the correct signature
  git symbolic-ref: documentation fix

t3040 (subprojects-basic): fix '&&' chaining, modernize style

Breaks in a test assertion's && chain can potentially hide failures
from earlier commands in the chain.  Fix instances of this.  While at
it, clean up the style to fit the prevailing style.  This means:

- Put the opening quote starting each test on the same line as the
  test_expect_* invocation.

- Indent the file with tabs, not spaces.

- Use test_expect_code() in preference to checking the exit status of
  various statements by hand.

- Guard commands that prepare test input for individual tests in the
  same test_expect_success, so that their scope is clearer and errors
  at that stage can be caught.

- Use <<-\EOF in preference to <<EOF to save readers the trouble of
  looking for variable interpolations.

- Include "setup" in the titles of test assertions that prepare for
  later ones to make it more obvious which tests can be skipped.

Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

am: don't persist keepcr flag

The keepcr flag is only used in the split_patches function, which is
only called before a patch application has to stopped for user input,
not after resuming. It is therefore unnecessary to persist the
flag. This seems to have been the case since it was introduced in
ad2c928 (git-am: Add command line parameter `--keep-cr` passing it to
git-mailsplit, 2010-02-27).

Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: give waitpid the correct signature

POSIX says that last parameter to waitpid should be 'int',
so let's make it so.

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

t1510 (worktree): fix '&&' chaining

Breaks in a test assertion's && chain can potentially hide failures
from earlier commands in the chain.

'unset' returns non-zero status when the variable passed was already unset
on some shells; we need to change these instances to 'sane_unset'.

Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3030 (merge-recursive): use test_expect_code

Use test_expect_code in preference to repeatedly checking exit codes
by hand.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-tag: introduce --cleanup option

Normally git tag strips tag message lines starting with '#', trailing
spaces from every line and empty lines from the beginning and end.

--cleanup allows to select different cleanup modes for tag message.
It provides the same interface as --cleanup option in git-commit.

Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui: handle shell script text filters when loading for blame.

When loading a file into the blame window git-gui does all the work and
must handle the text conversion filters if defined. On Windows it is
necessary to detect the need for a shell script explicitly.

Such filter commands are run using non-blocking I/O but this has the
unfortunate side effect of losing any error that might be reported when
the pipe is closed. Switching to blocking mode just before closing
enables reporting of errors in the filter scripts to the user.

Tested-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>

test: fix '&&' chaining

Breaks in a test assertion's && chain can potentially hide failures from
earlier commands in the chain by adding " &&" at the end of line to the
commands that need them.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3200 (branch): fix '&&' chaining

Breaks in a test assertion's && chain can potentially hide failures
from earlier commands in the chain.  Fix these breaks.

The 'git branch --help' in the test may fail if git manual pages are
not installed, but the point of the test is to make sure it does not
create a bogus branch "--help", so run it under 'test_might_fail'.

Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test: commit --amend should honor --no-edit

A quick test to make sure git doesn't lose the functionality added by
the recent patch "commit: honor --no-edit", plus another test to check
the classical --edit use case (use with "-m").

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit: honour --no-edit

After making fixes to the contents to be committed, it is not unusual to
update the current commit without rewording the message. Idioms to tell
"commit --amend" that we do not need an editor have been:

    $ EDITOR=: git commit --amend
    $ git commit --amend -C HEAD

but that was only because a more natural "--no-edit" option in

    $ git commit --amend --no-edit

was not honoured.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

t7501 (commit): modernize style

Put the opening quote starting each test on the same line as the
test_expect_* invocation.  While at it:

- guard commands that prepare test input for individual tests in
  the same test_expect_success, so their scope is clearer and
  errors at that stage can be caught;
- use the compare_diff_patch helper function when comparing patches;
- use single-quotes in preference to double-quotes and <<\EOF in
  preference to <<EOF, to save readers the trouble of looking for
  variable interpolations;
- lift the setting of the $author variable used throughout the
  test script to the top of the test script;
- include "setup" in the titles of test assertions that prepare for
  later ones to make it more obvious which tests can be skipped;
- use test_must_fail instead of "if ...; then:; else false; fi",
  for clarity and to catch segfaults when they happen;
- break up some pipelines into separate commands that read and write
  to ordinary files, and test the exit status at each stage;
- chain commands with &&.  Breaks in a test assertion's && chain can
  potentially hide failures from earlier commands in the chain;
- combine two initial tests that do not make as much sense alone.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test: remove a porcelain test that hard-codes commit names

The rev-list output in this test depends on the details of test_tick's
dummy dates and the choice of hash function.  Worse, it depends on the
order and nature of commits made in the earlier tests, so adding new
tests or rearranging existing ones breaks it.

It would be nice to check that "git commit" and commit-tree name
objects consistently and that commit objects' text is as documented,
but this particular test checks everything at once and hence is not a
robust test for that.  Remove it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test: add missing "&&" after echo command

This test wants to modify a file and commit the change, but because of
a missing separator between commands it is parsed as a single "echo"
command.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff/status: print submodule path when looking for changes fails

diff and status run "git status --porcelain" inside each populated
submodule to see if it contains changes (unless told not to do so via
config or command line option). When that fails, e.g. due to a corrupt
submodule .git directory, it just prints "git status --porcelain failed"
or "Could not run git status --porcelain" without giving the user a clue
where that happened.

Add '"in submodule %s", path' to these error strings to tell the user
where exactly the problem occurred.

Reported-by: Seth Robertson <in-gitvger@baka.org>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git symbolic-ref: documentation fix

The old "git symbolic-ref" manpage seemed to imply in one place that
symlinks are still the default way to represent symbolic references
and in another that symlinks are deprecated.  Fix the text and shorten
the justification for the change of implementation.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui: Set both 16x16 and 32x32 icons on X to pacify Xming.

It would be better if the 32x32 icon was equivalent to the one used on
Windows (in git-gui.ico), but I'm not sure how that would best be done,
so I copied this code from gitk instead.

Signed-off-by: Samuel Bronson <naesten@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>

reset: update cache-tree data when appropriate

In the case of --mixed and --hard, we throw away the old index and
rebuild everything from the tree argument (or HEAD).  So we have an
opportunity here to fill in the cache-tree data, just as read-tree
did.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit: write cache-tree data when writing index anyway

In prepare_index(), we refresh the index, and then write it to disk if
this changed the index data.  After running hooks we re-read the index
and compute the root tree sha1 with the cache-tree machinery.

This gives us a mostly free opportunity to write up-to-date cache-tree
data: we can compute it in prepare_index() immediately before writing
the index to disk.

If we do this, we were going to write the index anyway, and the later
cache-tree update has no further work to do.  If we don't do it, we
don't do any extra work, though we still don't have have cache-tree
data after the commit.

The only case that suffers badly is when the pre-commit hook changes
many trees in the index.  I'm writing this off as highly unusual.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Refactor cache_tree_update idiom from commit

We'll need to safely create or update the cache-tree data of the_index
from other places.  While at it, give it an argument that lets us
silence the messages produced by unmerged entries (which prevent it
from working).

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Test the current state of the cache-tree optimization

The cache-tree optimization originally helped speed up write-tree
operation.  However, many commands no longer properly maintain -- or
use an opportunity to cheaply generate -- the cache-tree data.  In
particular, this affects commit, checkout and reset.  The notable
examples that *do* write cache-tree data are read-tree and write-tree.

This sadly means most people no longer benefit from the optimization,
as they would not normally use the plumbing commands.

Document the current state of affairs in a test file, in preparation
for improvements in the area.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add test-scrap-cache-tree

A simple utility that invalidates all existing cache-tree data.  We
need this for tests.  (We don't need a tool to rebuild the cache-tree
data; git read-tree HEAD works for that.)

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

checkout -m: no need to insist on having all 3 stages

The content level merge machinery ll_merge() is prepared to merge
correctly in "both sides added differently" case by using an empty blob as
if it were the common ancestor. "checkout -m" could do the same, but didn't
bother supporting it and instead insisted on having all three stages.

Reported-by: Pete Harlan
Signed-off-by: Junio C Hamano <gitster@pobox.com>

userdiff: allow * between cpp funcname words

The cpp pattern, used for C and C++, would not match the start of a
declaration such as

  static char *prepare_index(int argc,

because it did not allow for * anywhere between the various words that
constitute the modifiers, type and function name.  Fix it.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

enable SO_KEEPALIVE for connected TCP sockets

Sockets may never receive notification of some link errors,
causing "git fetch" or similar processes to hang forever.
Enabling keepalive messages allows hung processes to error out
after a few minutes/hours depending on the keepalive settings of
the system.

This is a problem noticed when running non-interactive
cronjobs to mirror repositories using "git fetch".

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of git://bogomips.org/git-svn

* 'master' of git://bogomips.org/git-svn:
  git-svn.perl: close the edit for propedits even with no mods