tokkee.org

Merge branch 'jc/advice-doc'

* jc/advice-doc:
  advice: Document that they all default to true

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

* jc/request-pull-show-head-4:
  request-pull: do not emit "tag" before the tagname
  request-pull: update the "pull" command generation logic

Merge branch 'jc/pull-signed-tag'

* jc/pull-signed-tag:
  commit: do not lose mergetag header when not amending

Merge branch 'jc/checkout-m-twoway'

* jc/checkout-m-twoway:
  t/t2023-checkout-m.sh: fix use of test_must_fail

t/t2023-checkout-m.sh: fix use of test_must_fail

Change an invocation of test_must_fail() to be inside a
test_expect_success() as is our usual pattern. Having it outside
caused our tests to fail under prove(1) since we wouldn't print a
newline before TAP output:

    CONFLICT (content): Merge conflict in both.txt
    # GETTEXT POISON #ok 2 - -m restores 2-way conflicted+resolved file

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit: do not lose mergetag header when not amending

The earlier ed7a42a (commit: teach --amend to carry forward extra headers,
2011-11-08) broke "git merge/pull; edit to fix conflict; git commit"
workflow by forgetting that commit_tree_extended() takes the whole extra
header list.

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

Merge branch 'tr/cache-tree'

* tr/cache-tree:
  t0090: be prepared that 'wc -l' writes leading blanks

t0090: be prepared that 'wc -l' writes leading blanks

Use 'printf %d $(whatever|wc -l)' so that the shell removes the blanks
for us.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update draft release notes to 1.7.9

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

Merge branch 'ab/enable-i18n'

* ab/enable-i18n:
  i18n: add infrastructure for translating Git with gettext

Conflicts:
Makefile

Merge branch 'ew/keepalive'

* ew/keepalive:
  enable SO_KEEPALIVE for connected TCP sockets

Merge branch 'jc/checkout-m-twoway'

* jc/checkout-m-twoway:
  checkout_merged(): squelch false warning from some gcc
  Test 'checkout -m -- path'
  checkout -m: no need to insist on having all 3 stages

Merge branch 'jk/maint-push-over-dav'

* jk/maint-push-over-dav:
  http-push: enable "proactive auth"
  t5540: test DAV push with authentication

Conflicts:
http.c

Merge branch 'jk/fetch-no-tail-match-refs'

* jk/fetch-no-tail-match-refs:
  connect.c: drop path_match function
  fetch-pack: match refs exactly
  t5500: give fully-qualified refs to fetch-pack
  drop "match" parameter from get_remote_heads

Merge branch 'nd/resolve-ref'

* nd/resolve-ref:
  Rename resolve_ref() to resolve_ref_unsafe()
  Convert resolve_ref+xstrdup to new resolve_refdup function
  revert: convert resolve_ref() to read_ref_full()

Merge branch 'jn/maint-sequencer-fixes'

* jn/maint-sequencer-fixes:
  revert: stop creating and removing sequencer-old directory
  Revert "reset: Make reset remove the sequencer state"
  revert: do not remove state until sequence is finished
  revert: allow single-pick in the middle of cherry-pick sequence
  revert: pass around rev-list args in already-parsed form
  revert: allow cherry-pick --continue to commit before resuming
  revert: give --continue handling its own function

Merge branch 'jk/maint-snprintf-va-copy'

* jk/maint-snprintf-va-copy:
  compat/snprintf: don't look at va_list twice

Merge branch 'jk/maint-mv'

* jk/maint-mv:
  mv: be quiet about overwriting
  mv: improve overwrite warning
  mv: make non-directory destination error more clear
  mv: honor --verbose flag
  docs: mention "-k" for both forms of "git mv"

Merge branch 'ci/stripspace-docs'

* ci/stripspace-docs:
  Update documentation for stripspace

Merge branch 'rr/test-chaining'

* rr/test-chaining:
  t3401: use test_commit in setup
  t3401: modernize style
  t3040 (subprojects-basic): fix '&&' chaining, modernize style
  t1510 (worktree): fix '&&' chaining
  t3030 (merge-recursive): use test_expect_code
  test: fix '&&' chaining
  t3200 (branch): fix '&&' chaining

Merge branch 'tr/cache-tree'

* tr/cache-tree:
  reset: update cache-tree data when appropriate
  commit: write cache-tree data when writing index anyway
  Refactor cache_tree_update idiom from commit
  Test the current state of the cache-tree optimization
  Add test-scrap-cache-tree

Merge branch 'jk/credentials'

* jk/credentials:
  t: add test harness for external credential helpers
  credentials: add "store" helper
  strbuf: add strbuf_add*_urlencode
  Makefile: unix sockets may not available on some platforms
  credentials: add "cache" helper
  docs: end-user documentation for the credential subsystem
  credential: make relevance of http path configurable
  credential: add credential.*.username
  credential: apply helper config
  http: use credential API to get passwords
  credential: add function for parsing url components
  introduce credentials API
  t5550: fix typo
  test-lib: add test_config_global variant

Conflicts:
strbuf.c

request-pull: do not emit "tag" before the tagname

The whole point of the recent update to allow "git pull $url $tagname" is
so that the integrator does not have to store the (signed) tag that is
used to convey authenticity to be recorded in the resulting merge in the
local repository's tag namespace.  Asking for a merge be made with "git
pull $url tag $tagname" defeats it.

Note that the request can become ambiguous if the requestor has a branch
with the same name as the tag, but that is not a new problem limited to
pulling. I wouldn't mind if somebody wants to add disambiguation to the
find_matching_ref logic in the script as a separate patch, though.

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

advice: Document that they all default to true

By definition, the default value of "advice.*" variables must be true and
they all control various additional help messages that are designed to aid
new users. Setting one to false is to tell Git that the user understands
the nature of the error and does not need the additional verbose help
message.

Also fix the asciidoc markup for linkgit:git-checkout[1] in the
description of the detachedHead advice by removing an excess colon.

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

git-p4: fix skipSubmitEdit regression

Commit 7c766e5 (git-p4: introduce skipSubmitEdit, 2011-12-04)
made it easier to automate submission to p4, but broke the most
common case.

Add a test for when the user really does edit and save the change
template, and fix the bug that causes the test to fail.

Also add a confirmation message when submission is cancelled.

Reported-by: Michael Horowitz <michael.horowitz@ieee.org>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update draft release notes to 1.7.9

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

Merge branch 'jc/commit-amend-no-edit'

* jc/commit-amend-no-edit:
  test: commit --amend should honor --no-edit
  commit: honour --no-edit
  t7501 (commit): modernize style
  test: remove a porcelain test that hard-codes commit names
  test: add missing "&&" after echo command

Merge branch 'jc/stream-to-pack'

* jc/stream-to-pack:
  bulk-checkin: replace fast-import based implementation
  csum-file: introduce sha1file_checkpoint
  finish_tmp_packfile(): a helper function
  create_tmp_packfile(): a helper function
  write_pack_header(): a helper function

Conflicts:
pack.h

Merge branch 'aw/rebase-i-stop-on-failure-to-amend'

* aw/rebase-i-stop-on-failure-to-amend:
  rebase -i: interrupt rebase when "commit --amend" failed during "reword"

Merge branch 'jh/fast-import-notes'

* jh/fast-import-notes:
  fast-import: Fix incorrect fanout level when modifying existing notes refs
  t9301: Add 2nd testcase exposing bugs in fast-import's notes fanout handling
  t9301: Fix testcase covering up a bug in fast-import's notes fanout handling

Merge branch 'jk/upload-archive-use-start-command'

* jk/upload-archive-use-start-command:
  upload-archive: use start_command instead of fork

Merge git://ozlabs.org/~paulus/gitk

* git://ozlabs.org/~paulus/gitk:
  gitk: Make vi-style keybindings more vi-like
  gitk: Make "touching paths" search support backslashes
  gitk: Show modified files with separate work tree
  gitk: Simplify calculation of gitdir
  gitk: Run 'git rev-parse --git-dir' only once
  gitk: Put temporary directory inside .git
  gitk: Fix "External diff" with separate work tree
  gitk: Fix "blame parent commit" with separate work tree
  gitk: Fix "show origin of this line" with separate work tree
  gitk: Fix file highlight when run in subdirectory
  gitk: Update copyright
  gitk: When a commit contains a note, mark it with a yellow box
  gitk: Remember time zones from author and commit timestamps
  gitk: Remove unused $cdate array

request-pull: update the "pull" command generation logic

The old code that insisted on asking for the tip of a branch to be pulled
were not updated when we started allowing for a tag to be pulled. When a
tag points at an older part of the history and there is no branch that
points at the tagged commit, the script failed to say which ref is to be
pulled.

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

checkout_merged(): squelch false warning from some gcc

gcc 4.6.2 (there may be others) does not realize that the variable "mode"
can never be used uninitialized in this function and issues a false warning
under -Wuninitialized option.

Squelch it with an unnecessary initialization; it is not like a single
assignment matters to the performance in this codepath that writes out
to the filesystem with checkout_entry() anyway.

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

Update draft release notes to 1.7.9

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

Merge branch 'ks/tag-cleanup'

* ks/tag-cleanup:
  git-tag: introduce --cleanup option

Conflicts:
builtin/tag.c

Merge branch 'jl/submodule-status-failure-report'

* jl/submodule-status-failure-report:
  diff/status: print submodule path when looking for changes fails

Merge branch 'tr/userdiff-c-returns-pointer'

* tr/userdiff-c-returns-pointer:
  userdiff: allow * between cpp funcname words

Merge branch 'bc/maint-apply-check-no-patch'

* bc/maint-apply-check-no-patch:
  builtin/apply.c: report error on failure to recognize input
  t/t4131-apply-fake-ancestor.sh: fix broken test

Merge branch 'nd/ignore-might-be-precious'

* nd/ignore-might-be-precious:
  checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore

Merge branch 'jn/branch-move-to-self'

* jn/branch-move-to-self:
  Allow checkout -B <current-branch> to update the current branch
  branch: allow a no-op "branch -M <current-branch> HEAD"

Merge branch 'cn/maint-lf-to-crlf-filter'

* cn/maint-lf-to-crlf-filter:
  convert: track state in LF-to-CRLF filter

Merge branch 'tj/maint-imap-send-remove-unused'

* tj/maint-imap-send-remove-unused:
  imap-send: Remove unused 'use_namespace' variable

Merge branch 'jk/maint-upload-archive'

* jk/maint-upload-archive:
  archive: don't let remote clients get unreachable commits

Merge branch 'jn/gitweb-side-by-side-diff'

* jn/gitweb-side-by-side-diff:
  gitweb: Add navigation to select side-by-side diff
  gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
  t9500: Add basic sanity tests for side-by-side diff in gitweb
  t9500: Add test for handling incomplete lines in diff by gitweb
  gitweb: Give side-by-side diff extra CSS styling
  gitweb: Add a feature to show side-by-side diff
  gitweb: Extract formatting of diff chunk header
  gitweb: Refactor diff body line classification

Merge branch 'maint'

* maint:
  Update draft release notes for 1.7.8.1
  Git 1.7.7.5
  Git 1.7.6.5
  blame: don't overflow time buffer
  fetch: create status table using strbuf

Conflicts:
RelNotes

Update draft release notes for 1.7.8.1

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

Merge branch 'jc/maint-pack-object-cycle' into maint

* jc/maint-pack-object-cycle:
  pack-object: tolerate broken packs that have duplicated objects

Conflicts:
builtin/pack-objects.c

Merge branch 'jc/index-pack-reject-dups' into maint

* jc/index-pack-reject-dups:
  receive-pack, fetch-pack: reject bogus pack that records objects twice

Merge branch 'mf/curl-select-fdset' into maint

* mf/curl-select-fdset:
  http: drop "local" member from request struct
  http.c: Rely on select instead of tracking whether data was received
  http.c: Use timeout suggested by curl instead of fixed 50ms timeout
  http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping

Merge branch 'nd/misc-cleanups' into maint

* nd/misc-cleanups:
  unpack_object_header_buffer(): clear the size field upon error
  tree_entry_interesting: make use of local pointer "item"
  tree_entry_interesting(): give meaningful names to return values
  read_directory_recursive: reduce one indentation level
  get_tree_entry(): do not call find_tree_entry() on an empty tree
  tree-walk.c: do not leak internal structure in tree_entry_len()

Merge branch 'maint-1.7.7' into maint

* maint-1.7.7:
  Git 1.7.7.5
  Git 1.7.6.5
  blame: don't overflow time buffer
  fetch: create status table using strbuf
  checkout,merge: loosen overwriting untracked file check based on info/exclude
  cast variable in call to free() in builtin/diff.c and submodule.c
  apply: get rid of useless x < 0 comparison on a size_t type

Conflicts:
Documentation/git.txt
GIT-VERSION-GEN
RelNotes
builtin/fetch.c

Git 1.7.7.5

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

Merge branch 'ab/clang-lints' into maint-1.7.7

* ab/clang-lints:
  cast variable in call to free() in builtin/diff.c and submodule.c
  apply: get rid of useless x < 0 comparison on a size_t type

Merge branch 'nd/maint-ignore-exclude' into maint-1.7.7

* nd/maint-ignore-exclude:
  checkout,merge: loosen overwriting untracked file check based on info/exclude

Merge branch 'maint-1.7.6' into maint-1.7.7

* maint-1.7.6:
  Git 1.7.6.5
  blame: don't overflow time buffer
  fetch: create status table using strbuf

Conflicts:
Documentation/git.txt
GIT-VERSION-GEN
RelNotes

Git 1.7.6.5

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

Merge branch 'jk/maint-fetch-status-table' into maint-1.7.6

* jk/maint-fetch-status-table:
  fetch: create status table using strbuf

Merge branch 'jc/maint-name-rev-all' into maint-1.7.6

* jc/maint-name-rev-all:
  name-rev --all: do not even attempt to describe non-commit object

Merge branch 'ml/mailmap' into maint-1.7.6

* ml/mailmap:
  mailmap: xcalloc mailmap_info

Conflicts:
mailmap.c

blame: don't overflow time buffer

When showing the raw timestamp, we format the numeric
seconds-since-epoch into a buffer, followed by the timezone
string. This string has come straight from the commit
object. A well-formed object should have a timezone string
of only a few bytes, but we could be operating on data
pushed by a malicious user.

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

Merge branch 'master' of git://repo.or.cz/git-gui

* 'master' of git://repo.or.cz/git-gui: (28 commits)
  git-gui 0.16
  git-gui: handle shell script text filters when loading for blame.
  git-gui: Set both 16x16 and 32x32 icons on X to pacify Xming.
  git-gui: added config gui.gcwarning to disable the gc hint message
  git-gui: set whitespace warnings appropriate to this project
  git-gui: don't warn for detached head when rebasing
  git-gui: make config gui.warndetachedcommit a boolean
  git-gui: add config value gui.diffopts for passing additional diff options
  git-gui: sort the numeric ansi codes
  git-gui: support underline style when parsing diff output
  git-gui: fix spelling error in sshkey.tcl
  git-gui: include the file path in guitools confirmation dialog
  git-gui: span widgets over the full file output area in the blame view
  git-gui: use a tristate to control the case mode in the searchbar
  git-gui: set suitable extended window manager hints.
  git-gui: fix display of path in browser title
  git-gui: enable the smart case sensitive search only if gui.search.smartcase is true
  git-gui: catch invalid or complete regular expressions and treat as no match.
  git-gui: theme the search and line-number entry fields on blame screen
  git-gui: include the number of untracked files to stage when asking the user
  ...

http-push: enable "proactive auth"

Before commit 986bbc08, git was proactive about asking for
http passwords. It assumed that if you had a username in
your URL, you would also want a password, and asked for it
before making any http requests.

However, this could interfere with the use of .netrc (see
986bbc08 for details). And it was also unnecessary, since
the http fetching code had learned to recognize an HTTP 401
and prompt the user then. Furthermore, the proactive prompt
could interfere with the usage of .netrc (see 986bbc08 for
details).

Unfortunately, the http push-over-DAV code never learned to
recognize HTTP 401, and so was broken by this change. This
patch does a quick fix of re-enabling the "proactive auth"
strategy only for http-push, leaving the dumb http fetch and
smart-http as-is.

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

git-gui 0.16

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>

t5540: test DAV push with authentication

We don't currently test this case at all, and instead just
test the DAV mechanism over an unauthenticated push. That
isn't very realistic, as most people will want to
authenticate pushes.

Two of the tests expect_failure as they reveal bugs:

  1. Pushing without a username in the URL fails to ask for
     credentials when we get an HTTP 401. This has always
     been the case, but it would be nice if it worked like
     smart-http.

  2. Pushing with a username fails to ask for the password
     since 986bbc0 (http: don't always prompt for password,
     2011-11-04). This is a severe regression in v1.7.8, as
     authenticated push-over-DAV is now totally unusable
     unless you have credentials in your .netrc.

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

connect.c: drop path_match function

This function was used for comparing local and remote ref
names during fetch (which makes it a candidate for "most
confusingly named function of the year").

It no longer has any callers, so let's get rid of it.

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

fetch-pack: match refs exactly

When we are determining the list of refs to fetch via
fetch-pack, we have two sets of refs to compare: those on
the remote side, and a "match" list of things we want to
fetch. We iterate through the remote refs alphabetically,
seeing if each one is wanted by the "match" list.

Since def88e9 (Commit first cut at "git-fetch-pack",
2005-07-04), we have used the "path_match" function to do a
suffix match, where a remote ref is considered wanted if
any of the "match" elements is a suffix of the remote
refname.

This enables callers of fetch-pack to specify unqualified
refs and have them matched up with remote refs (e.g., ask
for "A" and get remote's "refs/heads/A"). However, if you
provide a fully qualified ref, then there are corner cases
where we provide the wrong answer. For example, given a
remote with two refs:

   refs/foo/refs/heads/master
   refs/heads/master

asking for "refs/heads/master" will first match
"refs/foo/refs/heads/master" by the suffix rule, and we will
erroneously fetch it instead of refs/heads/master.

As it turns out, all callers of fetch_pack do provide
fully-qualified refs for the match list. There are two ways
fetch_pack can get match lists:

  1. Through the transport code (i.e., via git-fetch)

  2. On the command-line of git-fetch-pack

In the first case, we will always be providing the names of
fully-qualified refs from "struct ref" objects. We will have
pre-matched those ref objects already (since we have to
handle more advanced matching, like wildcard refspecs), and
are just providing a list of the refs whose objects we need.

In the second case, users could in theory be providing
non-qualified refs on the command-line. However, the
fetch-pack documentation claims that refs should be fully
qualified (and has always done so since it was written in
2005).

Let's change this path_match call to simply check for string
equality, matching what the callers of fetch_pack are
expecting.

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

t5500: give fully-qualified refs to fetch-pack

The fetch-pack documentation is very clear that refs given
on the command line are to be full refs:

  <refs>...::
          The remote heads to update from. This is relative to
          $GIT_DIR (e.g. "HEAD", "refs/heads/master").  When
          unspecified, update from all heads the remote side has.

and this has been the case since fetch-pack was originally documented in
8b3d9dc ([PATCH] Documentation: clone/fetch/upload., 2005-07-14).

Let's follow our own documentation to set a good example,
and to avoid breaking when this restriction is enforced in
the next patch.

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

drop "match" parameter from get_remote_heads

The get_remote_heads function reads the list of remote refs
during git protocol session. It dates all the way back to
def88e9 (Commit first cut at "git-fetch-pack", 2005-07-04).
At that time, the idea was to come up with a list of refs we
were interested in, and then filter the list as we got it
from the remote side.

Later, 1baaae5 (Make maximal use of the remote refs,
2005-10-28) stopped filtering at the get_remote_heads layer,
letting us use the non-matching refs to find common history.

As a result, all callers now simply pass an empty match
list (and any future callers will want to do the same). So
let's drop these now-useless parameters.

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

Rename resolve_ref() to resolve_ref_unsafe()

resolve_ref() may return a pointer to a shared buffer and can be
overwritten by the next resolve_ref() calls. Callers need to
pay attention, not to keep the pointer when the next call happens.

Rename with "_unsafe" suffix to warn developers (or reviewers) before
introducing new call sites.

This patch is generated using the following command

git grep -l 'resolve_ref(' -- '*.[ch]'|xargs sed -i 's/resolve_ref(/resolve_ref_unsafe(/g'

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

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>

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>

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>

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>

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>

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>