tokkee.org

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

docs: brush up obsolete bits of git-fsck manpage

After the description and options, the fsck manpage contains
some discussion about what it does. Over time, this
discussion has become somewhat obsolete, both in content and
formatting. In particular:

  1. There are many options now, so starting the discussion
     with "It tests..." makes it unclear whether we are
     talking about the last option, or about the tool in
     general. Let's start a new "discussion" section and
     make our antecedent more clear.

  2. It gave an example for --unreachable using for-each-ref
     to mention all of the heads, saying that it will do "a
     _lot_ of verification". This is hopelessly out-of-date,
     as giving no arguments will check much more (reflogs,
     the index, non-head refs).

  3. It goes on to mention tests "to be added" (like tree
     object sorting). We now have these tests.

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

grep: disable threading in non-worktree case

Measurements by various people have shown that grepping in parallel is
not beneficial when the object store is involved.  For example, with a
simple regex:

  Threads     | --cached case            | worktree case
  ----------------------------------------------------------------
  8 (default) | 2.88u 0.21s 0:02.94real  | 0.19u 0.32s 0:00.16real
  4           | 2.89u 0.29s 0:02.99real  | 0.16u 0.34s 0:00.17real
  2           | 2.83u 0.36s 0:02.87real  | 0.18u 0.32s 0:00.26real
  NO_PTHREADS | 2.16u 0.08s 0:02.25real  | 0.12u 0.17s 0:00.31real

This happens because all the threads contend on read_sha1_mutex almost
all of the time.  A more complex regex allows the threads to do more
work in parallel, but as Jeff King found out, the "super boost" (much
higher clock when only one core is active) feature of recent CPUs
still causes the unthreaded case to win by a large margin.

So until the pack machinery allows unthreaded access, we disable
grep's threading in all but the worktree case.

Helped-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

grep: enable threading with -p and -W using lazy attribute lookup

Lazily load the userdiff attributes in match_funcname().  Use a
separate mutex around this loading to protect the (not thread-safe)
attributes machinery.  This lets us re-enable threading with -p and
-W while reducing the overhead caused by looking up attributes.

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

lf_to_crlf_filter(): tell the caller we added "\n" when draining

This can only happen when the input size is multiple of the
buffer size of the cascade filter (16k) and ends with an LF,
but in such a case, the code forgot to tell the caller that
it added the "\n" it could not add during the last round.

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

pretty: give placeholders to reflog identity

When doing a reflog walk, you can get some information about
the reflog (such as the subject line), but not the identity
information (i.e., name and email).

Let's make those available, mimicing the options for author
and committer identity.

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

use custom rename score during --follow

If you provide a custom rename score on the command line,
like:

  git log -M50 --follow foo.c

it is completely ignored, and there is no way to --follow
with a looser rename score. Instead, let's use the same
rename score that will be used for generating diffs. This is
convenient, and mirrors what we do with the break-score.

You can see an example of it being useful in git.git:

  $ git log --oneline --summary --follow \
    Documentation/technical/api-string-list.txt
  86d4b52 string-list: Add API to remove an item from an unsorted list
  1d2f80f string_list: Fix argument order for string_list_append
  e242148 string-list: add unsorted_string_list_lookup()
  0dda1d1 Fix two leftovers from path_list->string_list
  c455c87 Rename path_list to string_list
   create mode 100644 Documentation/technical/api-string-list.txt

  $ git log --oneline --summary -M40 --follow \
  Documentation/technical/api-string-list.txt
  86d4b52 string-list: Add API to remove an item from an unsorted list
  1d2f80f string_list: Fix argument order for string_list_append
  e242148 string-list: add unsorted_string_list_lookup()
  0dda1d1 Fix two leftovers from path_list->string_list
  c455c87 Rename path_list to string_list
   rename Documentation/technical/{api-path-list.txt => api-string-list.txt} (47%)
  328a475 path-list documentation: document all functions and data structures
  530e741 Start preparing the API documents.
   create mode 100644 Documentation/technical/api-path-list.txt

You could have two separate rename scores, one for following
and one for diff. But almost nobody is going to want that,
and it would just be unnecessarily confusing. Besides which,
we re-use the diff results from try_to_follow_renames for
the actual diff output, which means having them as separate
scores is actively wrong. E.g., with the current code, you
get:

  $ git log --oneline --diff-filter=R --name-status \
            -M90 --follow git.spec.in
  27dedf0 GIT 0.99.9j aka 1.0rc3
  R084    git-core.spec.in        git.spec.in
  f85639c Rename the RPM from "git" to "git-core"
  R098    git.spec.in     git-core.spec.in

The first one should not be considered a rename by the -M
score we gave, but we print it anyway, since we blindly
re-use the diff information from the follow (which uses the
default score). So this could also be considered simply a
bug-fix, as with the current code "-M" is completely ignored
when using "--follow".

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

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>

t3502, t3510: clarify cherry-pick -m failure

The "cherry-pick persists opts correctly" test in t3510
(cherry-pick-sequence) can cause some confusion, because the command
actually has two points of failure:

1. "-m 1" is specified on the command-line despite the base commit
   "initial" not being a merge-commit.
2. The revision range indicates that there will be a conflict that
   needs to be resolved.

Although the former error is trapped, and cherry-pick die()s with the
exit status 128, the reader may be distracted by the latter.  Fix this
by changing the revision range to something that wouldn't cause a
conflict.  Additionally, explicitly check the exit code in
"cherry-pick a non-merge with -m should fail" in t3502
(cherry-pick-merge) to reassure the reader that this failure has
nothing to do with the sequencer itself.

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

t3510 (cherry-pick-sequencer): use exit status

All the tests asserting failure use 'test_must_fail', which simply
checks for a non-zero exit status, potentially hiding underlying bugs.
So, replace instances of 'test_must_fail' with 'test_expect_code' to
check the exit status explicitly, where appropriate.

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

revert: simplify getting commit subject in format_todo()

format_todo() calls get_message(), but uses only the subject line of
the commit message.  As a minor optimization, save work and
unnecessary memory allocations by using find_commit_subject() instead.
Also, remove the unnecessary check on cur->item->buffer: the
lookup_commit_reference() call in parse_insn_line() has already made
sure of this.

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

revert: tolerate extra spaces, tabs in insn sheet

Tolerate extra spaces and tabs as part of the the field separator in
'.git/sequencer/todo', for people with fat fingers.

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

revert: make commit subjects in insn sheet optional

Change the instruction sheet format subtly so that the subject of the
commit message that follows the object name is optional.  As a result,
an instruction sheet like this is now perfectly valid:

  pick 35b0426
  pick fbd5bbcbc2e
  pick 7362160f

While at it, also fix a bug introduced by 5a5d80f4 (revert: Introduce
--continue to continue the operation, 2011-08-04) that failed to read
lines that are too long to fit on the commit-id-shaped buffer we
currently use; eliminate the need for the buffer altogether.  In
addition to literal SHA-1 hexes, you can now safely use expressions
like the following in the instruction sheet:

  featurebranch~4
  rr/revert-cherry-pick-continue^2~12@{12 days ago}

[jc: simplify parsing]

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

revert: free msg in format_todo()

Memory allocated to the fields of msg by get_message() isn't freed.
This is potentially a big leak, because fresh memory is allocated to
store the commit message for each commit.  Fix this using
free_message().

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

commit_tree(): refuse commit messages that contain NULs

Current implementation sees NUL as terminator. If users give a message
with NUL byte in it (e.g. editor set to save as UTF-16), the new commit
message will have NULs. However following operations (displaying or
amending a commit for example) will not keep anything after the first NUL.

Stop user right when they do this. If NUL is added by mistake, they have
their chance to fix. Otherwise, log messages will no longer be text "git
log" and friends would grok.

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

Convert commit_tree() to take strbuf as message

There wan't a way for commit_tree() to notice if the message the caller
prepared contained a NUL byte, as it did not take the length of the
message as a parameter. Use a pointer to a strbuf instead, so that we can
either choose to allow low-level plumbing commands to make commits that
contain NUL byte in its message, or forbid NUL everywhere by adding the
check in commit_tree(), in later patches.

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

merge: abort if fails to commit

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

test-lib: redirect stdin of tests

We want to run tests in a predictable, sterile environment
so we can get repeatable results.  They should take as
little input as possible from the environment outside the
test script. We already sanitize environment variables, but
leave stdin untouched. This means that scripts can
accidentally be impacted by content on stdin, or whether
stdin isatty().

Furthermore, scripts reading from stdin can be annoying to
outer loops which care about their stdin offset, like:

  while read sha1; do
      make test
  done

A test which accidentally reads stdin would soak up all of
the rest of the input intended for the outer shell loop.

Let's redirect stdin from /dev/null, which solves both
of these problems. It won't detect tests accidentally
reading from stdin, but since doing so now gives a
deterministic result, we don't need to consider that an
error.

We'll also leave file descriptor 6 as a link to the original
stdin. Tests shouldn't need to look at this, but it can be
convenient for inserting interactive commands while
debugging tests (e.g., you could insert "bash <&6 >&3 2>&4"
to run interactive commands in the environment of the test
script).

Signed-off-by: Jeff King <peff@peff.net>
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>

compat/setenv.c: error if name contains '='

According to POSIX, setenv should error out with EINVAL if it's
asked to set an environment variable whose name contains an equals
sign. Implement this detail in our compatibility-fallback.

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

compat/setenv.c: update errno when erroring out

Previously, gitsetenv didn't update errno as it should when
erroring out. Fix this.

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

test: errors preparing for a test are not special

This script uses the following idiom to start each test in a known
good state:

test_expect_success 'some commands use a pager' '
rm -f paginated.out || cleanup_fail &&
test_terminal git log &&
test -e paginated.out
'

where "cleanup_fail" is a function that prints an error message and
errors out.

That is bogus on three levels:

 - Cleanup commands like "rm -f" and "test_unconfig" are designed not
   to fail, so this logic would never trip.

 - If they were to malfunction anyway, it is not useful to set apart
   cleanup commands as a special kind of failure with a special error
   message.  Whichever command fails, the next step is to investigate
   which command that was, for example by running tests with
   "prove -e 'sh -x'", and fix it.

 - Relying on left-associativity of mixed &&/|| lists makes the code
   somewhat cryptic.

The fix is simple: drop the "|| cleanup_fail" in each test and the
definition of the "cleanup_fail" function so no new callers can arise.

Reported-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.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 '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>

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>