git/git.git
5 years agoremote.c: provide per-branch pushremote name
Jeff King [Thu, 21 May 2015 04:45:20 +0000 (00:45 -0400)]
remote.c: provide per-branch pushremote name

When remote.c loads its config, it records the
branch.*.pushremote for the current branch along with the
global remote.pushDefault value, and then binds them into a
single value: the default push for the current branch. We
then pass this value (which may be NULL) to remote_get_1
when looking up a remote for push.

This has a few downsides:

  1. It's confusing. The early-binding of the "current
     value" led to bugs like the one fixed by 98b406f
     (remote: handle pushremote config in any order,
     2014-02-24). And the fact that pushremotes fall back to
     ordinary remotes is not explicit at all; it happens
     because remote_get_1 cannot tell the difference between
     "we are not asking for the push remote" and "there is
     no push remote configured".

  2. It throws away intermediate data. After read_config()
     finishes, we have no idea what the value of
     remote.pushDefault was, because the string has been
     overwritten by the current branch's
     branch.*.pushremote.

  3. It doesn't record other data. We don't note the
     branch.*.pushremote value for anything but the current
     branch.

Let's make this more like the fetch-remote config. We'll
record the pushremote for each branch, and then explicitly
compute the correct remote for the current branch at the
time of reading.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoremote.c: hoist branch.*.remote lookup out of remote_get_1
Jeff King [Thu, 21 May 2015 04:45:16 +0000 (00:45 -0400)]
remote.c: hoist branch.*.remote lookup out of remote_get_1

We'll want to use this logic as a fallback when looking up
the pushremote, so let's pull it out into its own function.

We don't technically need to make this available outside of
remote.c, but doing so will provide a consistent API with
pushremote_for_branch, which we will add later.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoremote.c: drop "remote" pointer from "struct branch"
Jeff King [Thu, 21 May 2015 04:45:13 +0000 (00:45 -0400)]
remote.c: drop "remote" pointer from "struct branch"

When we create each branch struct, we fill in the
"remote_name" field from the config, and then fill in the
actual "remote" field (with a "struct remote") based on that
name. However, it turns out that nobody really cares about
the latter field. The only two sites that access it at all
are:

  1. git-merge, which uses it to notice when the branch does
     not have a remote defined. But we can easily replace this
     with looking at remote_name instead.

  2. remote.c itself, when setting up the @{upstream} merge
     config. But we don't need to save the "remote" in the
     "struct branch" for that; we can just look it up for
     the duration of the operation.

So there is no need to have both fields; they are redundant
with each other (the struct remote contains the name, or you
can look up the struct from the name). It would be nice to
simplify this, especially as we are going to add matching
pushremote config in a future patch (and it would be nice to
keep them consistent).

So which one do we keep and which one do we get rid of?

If we had a lot of callers accessing the struct, it would be
more efficient to keep it (since you have to do a lookup to
go from the name to the struct, but not vice versa). But we
don't have a lot of callers; we have exactly one, so
efficiency doesn't matter. We can decide this based on
simplicity and readability.

And the meaning of the struct value is somewhat unclear. Is
it always the remote matching remote_name? If remote_name is
NULL (i.e., no per-branch config), does the struct fall back
to the "origin" remote, or is it also NULL? These questions
will get even more tricky with pushremotes, whose fallback
behavior is more complicated. So let's just store the name,
which pretty clearly represents the branch.*.remote config.
Any lookup or fallback behavior can then be implemented in
helper functions.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5 years agoremote.c: refactor setup of branch->merge list
Jeff King [Thu, 21 May 2015 04:45:09 +0000 (00:45 -0400)]
remote.c: refactor setup of branch->merge list

When we call branch_get() to lookup or create a "struct
branch", we make sure the "merge" field is filled in so that
callers can access it. But the conditions under which we do
so are a little confusing, and can lead to two funny
situations:

  1. If there's no branch.*.remote config, we cannot provide
     branch->merge (because it is really just an application
     of branch.*.merge to our remote's refspecs). But
     branch->merge_nr may be non-zero, leading callers to be
     believe they can access branch->merge (e.g., in
     branch_merge_matches and elsewhere).

     It doesn't look like this can cause a segfault in
     practice, as most code paths dealing with merge config
     will bail early if there is no remote defined. But it's
     a bit of a dangerous construct.

     We can fix this by setting merge_nr to "0" explicitly
     when we realize that we have no merge config. Note that
     merge_nr also counts the "merge_name" fields (which we
     _do_ have; that's how merge_nr got incremented), so we
     will "lose" access to them, in the sense that we forget
     how many we had. But no callers actually care; we use
     merge_name only while iteratively reading the config,
     and then convert it to the final "merge" form the first
     time somebody calls branch_get().

  2. We set up the "merge" field every time branch_get is
     called, even if it has already been done. This leaks
     memory.

     It's not a big deal in practice, since most code paths
     will access only one branch, or perhaps each branch
     only one time. But if you want to be pathological, you
     can leak arbitrary memory with:

       yes @{upstream} | head -1000 | git rev-list --stdin

     We can fix this by skipping setup when branch->merge is
     already non-NULL.

In addition to those two fixes, this patch pushes the "do we
need to setup merge?" logic down into set_merge, where it is
a bit easier to follow.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoremote.c: drop default_remote_name variable
Jeff King [Fri, 1 May 2015 22:44:41 +0000 (18:44 -0400)]
remote.c: drop default_remote_name variable

When we read the remote config from disk, we update a
default_remote_name variable if we see branch.*.remote
config for the current branch. This isn't wrong, or even all
that complicated, but it is a bit simpler (because it
reduces our overall state) to just lazily compute the
default when we need it.

The ulterior motive here is that the push config uses a
similar structure, and _is_ much more complicated as a
result. That will be simplified in a future patch, and it's
more readable if the logic for remotes and push-remotes
matches.

Note that we also used default_remote_name as a signal that
the remote config has been loaded; after this patch, we now
use an explicit flag.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoGit 2.4.0-rc0 v2.4.0-rc0
Junio C Hamano [Thu, 26 Mar 2015 18:59:05 +0000 (11:59 -0700)]
Git 2.4.0-rc0

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMerge branch 'jk/test-chain-lint'
Junio C Hamano [Thu, 26 Mar 2015 18:57:13 +0000 (11:57 -0700)]
Merge branch 'jk/test-chain-lint'

People often forget to chain the commands in their test together
with &&, leaving a failure from an earlier command in the test go
unnoticed.  The new GIT_TEST_CHAIN_LINT mechanism allows you to
catch such a mistake more easily.

* jk/test-chain-lint: (36 commits)
  t9001: drop save_confirm helper
  t0020: use test_* helpers instead of hand-rolled messages
  t: simplify loop exit-code status variables
  t: fix some trivial cases of ignored exit codes in loops
  t7701: fix ignored exit code inside loop
  t3305: fix ignored exit code inside loop
  t0020: fix ignored exit code inside loops
  perf-lib: fix ignored exit code inside loop
  t6039: fix broken && chain
  t9158, t9161: fix broken &&-chain in git-svn tests
  t9104: fix test for following larger parents
  t4104: drop hand-rolled error reporting
  t0005: fix broken &&-chains
  t7004: fix embedded single-quotes
  t0050: appease --chain-lint
  t9001: use test_when_finished
  t4117: use modern test_* helpers
  t6034: use modern test_* helpers
  t1301: use modern test_* helpers
  t0020: use modern test_* helpers
  ...

6 years agoMerge branch 'sg/completion-gitcomp-nl-for-refs'
Junio C Hamano [Thu, 26 Mar 2015 18:57:13 +0000 (11:57 -0700)]
Merge branch 'sg/completion-gitcomp-nl-for-refs'

Code clean-up.

* sg/completion-gitcomp-nl-for-refs:
  completion: use __gitcomp_nl() for completing refs

6 years agoMerge branch 'jc/report-path-error-to-dir'
Junio C Hamano [Thu, 26 Mar 2015 18:57:12 +0000 (11:57 -0700)]
Merge branch 'jc/report-path-error-to-dir'

Code clean-up.

* jc/report-path-error-to-dir:
  report_path_error(): move to dir.c

6 years agoGetting ready for -rc0
Junio C Hamano [Wed, 25 Mar 2015 20:01:07 +0000 (13:01 -0700)]
Getting ready for -rc0

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMerge branch 'nd/doc-git-index-version'
Junio C Hamano [Wed, 25 Mar 2015 19:54:28 +0000 (12:54 -0700)]
Merge branch 'nd/doc-git-index-version'

Doc clean-up.

* nd/doc-git-index-version:
  git.txt: list index versions in plain English

6 years agoMerge branch 'jk/run-command-capture'
Junio C Hamano [Wed, 25 Mar 2015 19:54:27 +0000 (12:54 -0700)]
Merge branch 'jk/run-command-capture'

The run-command interface was easy to abuse and make a pipe for us
to read from the process, wait for the process to finish and then
attempt to read its output, which is a pattern that lead to a
deadlock.  Fix such uses by introducing a helper to do this
correctly (i.e. we need to read first and then wait the process to
finish) and also add code to prevent such abuse in the run-command
helper.

* jk/run-command-capture:
  run-command: forbid using run_command with piped output
  trailer: use capture_command
  submodule: use capture_command
  wt-status: use capture_command
  run-command: introduce capture_command helper
  wt_status: fix signedness mismatch in strbuf_read call
  wt-status: don't flush before running "submodule status"

6 years agoMerge branch 'tg/test-index-v4'
Junio C Hamano [Wed, 25 Mar 2015 19:54:27 +0000 (12:54 -0700)]
Merge branch 'tg/test-index-v4'

A test fix.

* tg/test-index-v4:
  t1700: make test pass with index-v4

6 years agoMerge branch 'jk/prune-with-corrupt-refs'
Junio C Hamano [Wed, 25 Mar 2015 19:54:26 +0000 (12:54 -0700)]
Merge branch 'jk/prune-with-corrupt-refs'

"git prune" used to largely ignore broken refs when deciding which
objects are still being used, which could spread an existing small
damage and make it a larger one.

* jk/prune-with-corrupt-refs:
  refs.c: drop curate_packed_refs
  repack: turn on "ref paranoia" when doing a destructive repack
  prune: turn on ref_paranoia flag
  refs: introduce a "ref paranoia" flag
  t5312: test object deletion code paths in a corrupted repository

6 years agoMerge branch 'tg/fix-check-order-with-split-index'
Junio C Hamano [Wed, 25 Mar 2015 19:54:26 +0000 (12:54 -0700)]
Merge branch 'tg/fix-check-order-with-split-index'

The split-index mode introduced at v2.3.0-rc0~41 was broken in the
codepath to protect us against a broken reimplementation of Git
that writes an invalid index with duplicated index entries, etc.

* tg/fix-check-order-with-split-index:
  read-cache: fix reading of split index

6 years agoMerge branch 'jk/fetch-pack'
Junio C Hamano [Wed, 25 Mar 2015 19:54:25 +0000 (12:54 -0700)]
Merge branch 'jk/fetch-pack'

"git fetch" that fetches a commit using the allow-tip-sha1-in-want
extension could have failed to fetch all the requested refs.

* jk/fetch-pack:
  fetch-pack: remove dead assignment to ref->new_sha1
  fetch_refs_via_pack: free extra copy of refs
  filter_ref: make a copy of extra "sought" entries
  filter_ref: avoid overwriting ref->old_sha1 with garbage

6 years agoMerge branch 'jk/cleanup-failed-clone'
Junio C Hamano [Wed, 25 Mar 2015 19:54:24 +0000 (12:54 -0700)]
Merge branch 'jk/cleanup-failed-clone'

An failure early in the "git clone" that started creating the
working tree and repository could have resulted in some directories
and files left without getting cleaned up.

* jk/cleanup-failed-clone:
  clone: drop period from end of die_errno message
  clone: initialize atexit cleanup handler earlier

6 years agoMerge branch 'jc/submitting-patches-mention-send-email'
Junio C Hamano [Wed, 25 Mar 2015 19:54:23 +0000 (12:54 -0700)]
Merge branch 'jc/submitting-patches-mention-send-email'

Recommend format-patch and send-email for those who want to submit
patches to this project.

* jc/submitting-patches-mention-send-email:
  SubmittingPatches: encourage users to use format-patch and send-email

6 years agoMerge branch 'dj/log-graph-with-no-walk'
Junio C Hamano [Wed, 25 Mar 2015 19:54:22 +0000 (12:54 -0700)]
Merge branch 'dj/log-graph-with-no-walk'

"git log --graph --no-walk A B..." is a otcnflicting request that
asks nonsense; no-walk tells us show discrete points in the
history, while graph asks to draw connections between these
discrete points. Forbid the combination.

* dj/log-graph-with-no-walk:
  revision: forbid combining --graph and --no-walk

6 years agoMerge branch 'kd/rev-list-bisect-first-parent'
Junio C Hamano [Wed, 25 Mar 2015 19:54:21 +0000 (12:54 -0700)]
Merge branch 'kd/rev-list-bisect-first-parent'

"git rev-list --bisect --first-parent" does not work (yet) and can
even cause SEGV; forbid it.  "git log --bisect --first-parent"
would not be useful until "git bisect --first-parent" materializes,
so it is also forbidden for now.

* kd/rev-list-bisect-first-parent:
  rev-list: refuse --first-parent combined with --bisect

6 years agoMerge branch 'ws/grep-quiet-no-pager'
Junio C Hamano [Wed, 25 Mar 2015 19:54:20 +0000 (12:54 -0700)]
Merge branch 'ws/grep-quiet-no-pager'

Even though "git grep --quiet" is run merely to ask for the exit
status, we spawned the pager regardless.  Stop doing that.

* ws/grep-quiet-no-pager:
  grep: fix "--quiet" overwriting current output

6 years agoMerge branch 'jk/simplify-csum-file-sha1fd-check'
Junio C Hamano [Wed, 25 Mar 2015 19:54:19 +0000 (12:54 -0700)]
Merge branch 'jk/simplify-csum-file-sha1fd-check'

Code simplification.

* jk/simplify-csum-file-sha1fd-check:
  sha1fd_check: die when we cannot open the file

6 years agoMerge branch 'ct/prompt-untracked-fix'
Junio C Hamano [Wed, 25 Mar 2015 19:54:18 +0000 (12:54 -0700)]
Merge branch 'ct/prompt-untracked-fix'

The prompt script (in contrib/) did not show the untracked sign
when working in a subdirectory without any untracked files.

* ct/prompt-untracked-fix:
  git prompt: use toplevel to find untracked files

6 years agot9001: drop save_confirm helper
Jeff King [Wed, 25 Mar 2015 05:32:20 +0000 (01:32 -0400)]
t9001: drop save_confirm helper

The idea of this helper is that we want to save the current
value of a config variable and then restore it again after
the test completes. However, there's no point in actually
saving the value; it should always be restored to the string
"never" (which you can confirm by instrumenting
save_confirm to print the value it finds).

Let's just replace it with a single test_when_finished call.

Suggested-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot0020: use test_* helpers instead of hand-rolled messages
Jeff King [Wed, 25 Mar 2015 05:31:41 +0000 (01:31 -0400)]
t0020: use test_* helpers instead of hand-rolled messages

These tests are not wrong, but it is much shorter and more
idiomatic to say "verbose" or "test_must_fail" rather than
printing our own messages on failure. Likewise, there is no
need to say "happy" at the end of a test; the test suite
takes care of that.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot: simplify loop exit-code status variables
Jeff King [Wed, 25 Mar 2015 05:30:17 +0000 (01:30 -0400)]
t: simplify loop exit-code status variables

Since shell loops may drop the exit code of failed commands
inside the loop, some tests try to keep track of the status
by setting a variable. This can end up cumbersome and hard
to read; it is much simpler to just exit directly from the
loop using "return 1" (since each case is either in a helper
function or inside a test snippet).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot: fix some trivial cases of ignored exit codes in loops
Jeff King [Wed, 25 Mar 2015 05:29:52 +0000 (01:29 -0400)]
t: fix some trivial cases of ignored exit codes in loops

These are all cases where we do a setup step of the form:

  for i in $foo; do
  set_up $i || break
  done &&
  more_setup

would not notice a failure in set_up (because break always
returns a 0 exit code). These are just setup steps that we
do not expect to fail, but it does not hurt to be defensive.

Most can be fixed by converting the "break" to a "return 1"
(since we eval our tests inside a function for just this
purpose). A few of the loops are inside subshells, so we can
use just "exit 1" to break out of the subshell. And a few
can actually be made shorter by just unrolling the loop.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot7701: fix ignored exit code inside loop
Jeff King [Wed, 25 Mar 2015 05:29:10 +0000 (01:29 -0400)]
t7701: fix ignored exit code inside loop

When checking a list of file mtimes, we use a loop and break
out early from the loop if any entry does not match.
However, the exit code of a loop exited via break is always
0, meaning that the test will fail to notice we had a
mismatch. Since the loop is inside a function, we can fix
this by doing an early "return 1".

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot3305: fix ignored exit code inside loop
Jeff King [Wed, 25 Mar 2015 05:28:57 +0000 (01:28 -0400)]
t3305: fix ignored exit code inside loop

When we test deleting notes, we run "git notes remove" in a
loop. However, the exit value of the loop will only reflect
the final note we process. We should break out of the loop
with a failing exit code as soon as we see a problem.

Note that we can call "exit 1" here without explicitly
creating a subshell, because the while loop on the
right-hand side of a pipe executes in its own implicit
subshell.

Note also that the "break" above does not suffer the same
problem; it is meant to exit the loop early at a certain
number of iterations. We can bump it into the conditional of
the loop to make this more obvious.

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot0020: fix ignored exit code inside loops
Jeff King [Wed, 25 Mar 2015 05:28:44 +0000 (01:28 -0400)]
t0020: fix ignored exit code inside loops

A loop like:

  for f in one two; do
  something $f ||
  break
  done

will correctly break out of the loop when we see a failure
of one item, but the resulting exit code will always be
zero. We can fix that by putting the loop into a function or
subshell, but in this case it is simpler still to just
unroll the loop. We do add a helper function, which
hopefully makes the end result even more readable (in
addition to being shorter).

Reported-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoperf-lib: fix ignored exit code inside loop
Jeff King [Wed, 25 Mar 2015 05:25:55 +0000 (01:25 -0400)]
perf-lib: fix ignored exit code inside loop

When copying the test repository, we try to detect whether
the copy succeeded. However, most of the heavy lifting is
done inside a for loop, where our "break" will lose the exit
code of the failing "cp". We can take advantage of the fact
that we are in a subshell, and just "exit 1" to break out
with a code.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMerge branch 'master' of git://ozlabs.org/~paulus/gitk
Junio C Hamano [Tue, 24 Mar 2015 23:10:37 +0000 (16:10 -0700)]
Merge branch 'master' of git://ozlabs.org/~paulus/gitk

* 'master' of git://ozlabs.org/~paulus/gitk:
  gitk: Update .po files
  gitk: l10n: Add Catalan translation
  gitk: Fix typo in Russian translation
  gitk: Remove tcl-format flag from a message that shouldn't have it
  gitk: Pass --invert-grep option down to "git log"
  gitk: Synchronize config file writes
  gitk: Report errors in saving config file
  gitk: Only write changed configuration variables
  gitk: Enable mouse horizontal scrolling in diff pane
  gitk: Default wrcomcmd to use --pretty=email

6 years agoreport_path_error(): move to dir.c
Junio C Hamano [Tue, 24 Mar 2015 21:12:10 +0000 (14:12 -0700)]
report_path_error(): move to dir.c

The expected call sequence is for the caller to use match_pathspec()
repeatedly on a set of pathspecs, accumulating the "hits" in a
separate array, and then call this function to diagnose a pathspec
that never matched anything, as that can indicate a typo from the
command line, e.g. "git commit Maekfile".

Many builtin commands use this function from builtin/ls-files.c,
which is not a very healthy arrangement.  ls-files might have been
the first command to feel the need for such a helper, but the need
is shared by everybody who uses the "match and then report" pattern.

Move it to dir.c where match_pathspec() is defined.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agogit.txt: list index versions in plain English
Nguyễn Thái Ngọc Duy [Tue, 24 Mar 2015 00:28:33 +0000 (07:28 +0700)]
git.txt: list index versions in plain English

At the first look, a user may think the default version is "23". Even
with UNIX background, there's no reference anywhere close that may
indicate this is glob or regex.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoSync with v2.3.4
Junio C Hamano [Mon, 23 Mar 2015 18:37:49 +0000 (11:37 -0700)]
Sync with v2.3.4

6 years agoPost 2.3 cycle (batch #12)
Junio C Hamano [Mon, 23 Mar 2015 18:36:01 +0000 (11:36 -0700)]
Post 2.3 cycle (batch #12)

Hopefully with another batch or two, we would be ready for -rc0
to close this cycle.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMerge branch 'js/completion-ctags-pattern-substitution-fix'
Junio C Hamano [Mon, 23 Mar 2015 18:28:16 +0000 (11:28 -0700)]
Merge branch 'js/completion-ctags-pattern-substitution-fix'

The code that reads from the ctags file in the completion script
(in contrib/) did not spell ${param/pattern/string} substitution
correctly, which happened to work with bash but not with zsh.

* js/completion-ctags-pattern-substitution-fix:
  contrib/completion: escape the forward slash in __git_match_ctag

6 years agoMerge branch 'jk/push-config'
Junio C Hamano [Mon, 23 Mar 2015 18:28:13 +0000 (11:28 -0700)]
Merge branch 'jk/push-config'

Restructure "git push" codepath to make it easier to add new
configuration bits and then add push.followTags configuration that
turns --follow-tags option on by default.

* jk/push-config:
  push: allow --follow-tags to be set by config push.followTags
  cmd_push: pass "flags" pointer to config callback
  cmd_push: set "atomic" bit directly
  git_push_config: drop cargo-culted wt_status pointer

6 years agoMerge branch 'nd/config-doc-camelCase'
Junio C Hamano [Mon, 23 Mar 2015 18:28:12 +0000 (11:28 -0700)]
Merge branch 'nd/config-doc-camelCase'

Documentation updates.

* nd/config-doc-camelCase:
  *config.txt: stick to camelCase naming convention

6 years agoMerge branch 'jk/test-annoyances'
Junio C Hamano [Mon, 23 Mar 2015 18:28:10 +0000 (11:28 -0700)]
Merge branch 'jk/test-annoyances'

Test fixes.

* jk/test-annoyances:
  t5551: make EXPENSIVE test cheaper
  t5541: move run_with_cmdline_limit to test-lib.sh
  t: pass GIT_TRACE through Apache
  t: redirect stderr GIT_TRACE to descriptor 4
  t: translate SIGINT to an exit

6 years agoMerge branch 'jk/smart-http-hide-refs'
Junio C Hamano [Mon, 23 Mar 2015 18:28:08 +0000 (11:28 -0700)]
Merge branch 'jk/smart-http-hide-refs'

The transfer.hiderefs support did not quite work for smart-http
transport.

* jk/smart-http-hide-refs:
  upload-pack: do not check NULL return of lookup_unknown_object
  upload-pack: fix transfer.hiderefs over smart-http

6 years agoMerge branch 'jk/tag-h-column-is-a-listing-option'
Junio C Hamano [Mon, 23 Mar 2015 18:28:02 +0000 (11:28 -0700)]
Merge branch 'jk/tag-h-column-is-a-listing-option'

"git tag -h" used to show the "--column" and "--sort" options
that are about listing in a wrong section.

* jk/tag-h-column-is-a-listing-option:
  tag: fix some mis-organized options in "-h" listing

6 years agoGit 2.3.4 v2.3.4
Junio C Hamano [Mon, 23 Mar 2015 18:27:27 +0000 (11:27 -0700)]
Git 2.3.4

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMerge branch 'rs/use-isxdigit' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:41 +0000 (11:23 -0700)]
Merge branch 'rs/use-isxdigit' into maint

Code cleanup.

* rs/use-isxdigit:
  use isxdigit() for checking if a character is a hexadecimal digit

6 years agoMerge branch 'rs/deflate-init-cleanup' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:37 +0000 (11:23 -0700)]
Merge branch 'rs/deflate-init-cleanup' into maint

Code simplification.

* rs/deflate-init-cleanup:
  zlib: initialize git_zstream in git_deflate_init{,_gzip,_raw}

6 years agoMerge branch 'ak/git-done-help-cleanup' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:35 +0000 (11:23 -0700)]
Merge branch 'ak/git-done-help-cleanup' into maint

Code simplification.

* ak/git-done-help-cleanup:
  git: make was_alias and done_help non-static

6 years agoMerge branch 'sg/completion-remote' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:33 +0000 (11:23 -0700)]
Merge branch 'sg/completion-remote' into maint

Code simplification.

* sg/completion-remote:
  completion: simplify __git_remotes()
  completion: add a test for __git_remotes() helper function

6 years agoMerge branch 'mg/doc-status-color-slot' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:30 +0000 (11:23 -0700)]
Merge branch 'mg/doc-status-color-slot' into maint

Documentation fixes.

* mg/doc-status-color-slot:
  config,completion: add color.status.unmerged

6 years agoMerge branch 'jc/decorate-leaky-separator-color' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:28 +0000 (11:23 -0700)]
Merge branch 'jc/decorate-leaky-separator-color' into maint

"git log --decorate" did not reset colors correctly around the
branch names.

* jc/decorate-leaky-separator-color:
  log --decorate: do not leak "commit" color into the next item
  Documentation/config.txt: simplify boolean description in the syntax section
  Documentation/config.txt: describe 'color' value type in the "Values" section
  Documentation/config.txt: have a separate "Values" section
  Documentation/config.txt: describe the structure first and then meaning
  Documentation/config.txt: explain multi-valued variables once
  Documentation/config.txt: avoid unnecessary negation

6 years agoMerge branch 'kn/git-cd-to-empty' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:25 +0000 (11:23 -0700)]
Merge branch 'kn/git-cd-to-empty' into maint

"git -C '' subcmd" refused to work in the current directory, unlike
"cd ''" which silently behaves as a no-op.

* kn/git-cd-to-empty:
  git: treat "git -C '<path>'" as a no-op when <path> is empty

6 years agoMerge branch 'km/imap-send-libcurl-options' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:22 +0000 (11:23 -0700)]
Merge branch 'km/imap-send-libcurl-options' into maint

"git imap-send" learned to optionally talk with an IMAP server via
libcURL; because there is no other option when Git is built with
NO_OPENSSL option, use that codepath by default under such
configuration.

* km/imap-send-libcurl-options:
  imap-send: use cURL automatically when NO_OPENSSL defined

6 years agoMerge branch 'mg/verify-commit' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:19 +0000 (11:23 -0700)]
Merge branch 'mg/verify-commit' into maint

Workarounds for certain build of GPG that triggered false breakage
in a test.

* mg/verify-commit:
  t7510: do not fail when gpg warns about insecure memory

6 years agoMerge branch 'es/rebase-i-count-todo' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:17 +0000 (11:23 -0700)]
Merge branch 'es/rebase-i-count-todo' into maint

"git rebase -i" recently started to include the number of
commits in the insn sheet to be processed, but on a platform
that prepends leading whitespaces to "wc -l" output, the numbers
are shown with extra whitespaces that aren't necessary.

* es/rebase-i-count-todo:
  rebase-interactive: re-word "item count" comment
  rebase-interactive: suppress whitespace preceding item count

6 years agoMerge branch 'tb/connect-ipv6-parse-fix' into maint
Junio C Hamano [Mon, 23 Mar 2015 18:23:12 +0000 (11:23 -0700)]
Merge branch 'tb/connect-ipv6-parse-fix' into maint

We did not parse username followed by literal IPv6 address in SSH
transport URLs, e.g. ssh://user@[2001:db8::1]:22/repo.git
correctly.

* tb/connect-ipv6-parse-fix:
  t5500: show user name and host in diag-url
  t5601: add more test cases for IPV6
  connect.c: allow ssh://user@[2001:db8::1]/repo.git

6 years agorun-command: forbid using run_command with piped output
Jeff King [Mon, 23 Mar 2015 03:54:05 +0000 (23:54 -0400)]
run-command: forbid using run_command with piped output

Because run_command both spawns and wait()s for the command
before returning control to the caller, any reads from the
pipes we open must necessarily happen after wait() returns.
This can lead to deadlock, as the child process may block
on writing to us while we are blocked waiting for it to
exit.

Worse, it only happens when the child fills the pipe
buffer, which means that the problem may come and go
depending on the platform and the size of the output
produced by the child.

Let's detect and flag this dangerous construct so that we
can catch potential bugs early in the test suite rather than
having them happen in the field.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agotrailer: use capture_command
Jeff King [Mon, 23 Mar 2015 03:54:00 +0000 (23:54 -0400)]
trailer: use capture_command

When we read from a trailer.*.command sub-program, the
current code uses run_command followed by a pipe read, which
can result in deadlock (though in practice you would have to
have a large trailer for this to be a problem). The current
code also leaks the file descriptor for the pipe to the
sub-command.

Instead, let's use capture_command, which makes this simpler
(and we can get rid of our custom helper).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agosubmodule: use capture_command
Jeff King [Mon, 23 Mar 2015 03:53:56 +0000 (23:53 -0400)]
submodule: use capture_command

In is_submodule_commit_present, we call run_command followed
by a pipe read, which is prone to deadlock. It is unlikely
to happen in this case, as rev-list should never produce
more than a single line of output, but it does not hurt to
avoid an anti-pattern (and using the helper simplifies the
setup and cleanup).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agowt-status: use capture_command
Jeff King [Mon, 23 Mar 2015 03:53:52 +0000 (23:53 -0400)]
wt-status: use capture_command

When we spawn "git submodule status" to read its output, we
use run_command() followed by strbuf_read() read from the
pipe. This can deadlock if the subprocess output is larger
than the system pipe buffer.

Furthermore, if start_command() fails, we'll try to read
from a bogus descriptor (probably "-1" or a descriptor we
just closed, but it is a bad idea for us to make assumptions
about how start_command implements its error handling). And
if start_command succeeds, we leak the file descriptor for
the pipe to the child.

All of these can be solved by using the capture_command
helper.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agorun-command: introduce capture_command helper
Jeff King [Mon, 23 Mar 2015 03:53:43 +0000 (23:53 -0400)]
run-command: introduce capture_command helper

Something as simple as reading the stdout from a command
turns out to be rather hard to do right. Doing:

  cmd.out = -1;
  run_command(&cmd);
  strbuf_read(&buf, cmd.out, 0);

can result in deadlock if the child process produces a large
amount of output. What happens is:

  1. The parent spawns the child with its stdout connected
     to a pipe, of which the parent is the sole reader.

  2. The parent calls wait(), blocking until the child exits.

  3. The child writes to stdout. If it writes more data than
     the OS pipe buffer can hold, the write() call will
     block.

This is a deadlock; the parent is waiting for the child to
exit, and the child is waiting for the parent to call
read().

So we might try instead:

  start_command(&cmd);
  strbuf_read(&buf, cmd.out, 0);
  finish_command(&cmd);

But that is not quite right either. We are examining cmd.out
and running finish_command whether start_command succeeded
or not, which is wrong. Moreover, these snippets do not do
any error handling. If our read() fails, we must make sure
to still call finish_command (to reap the child process).
And both snippets failed to close the cmd.out descriptor,
which they must do (provided start_command succeeded).

Let's introduce a run-command helper that can make this a
bit simpler for callers to get right.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agocompletion: use __gitcomp_nl() for completing refs
SZEDER Gábor [Sun, 22 Mar 2015 12:03:11 +0000 (13:03 +0100)]
completion: use __gitcomp_nl() for completing refs

We do that almost everywhere, because it's faster for large number of
refs, see a31e62629 (completion: optimize refs completion, 2011-10-15).
These were the last two places where we still used __gitcomp() for
completing refs.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agowt_status: fix signedness mismatch in strbuf_read call
Jeff King [Sun, 22 Mar 2015 10:00:32 +0000 (06:00 -0400)]
wt_status: fix signedness mismatch in strbuf_read call

We call strbuf_read(), and want to know whether we got any
output. To do so, we assign the result to a size_t, and
check whether it is non-zero.

But strbuf_read returns a signed ssize_t. If it encounters
an error, it will return -1, and we'll end up treating this
the same as if we had gotten output. Instead, we can just
check whether our buffer has anything in it (which is what
we care about anyway, and is the same thing since we know
the buffer was empty to begin with).

Note that the "len" variable actually has two roles in this
function. Now that we've eliminated the first, we can push the
declaration closer to the point of use for the second one.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agowt-status: don't flush before running "submodule status"
Jeff King [Sun, 22 Mar 2015 10:00:01 +0000 (06:00 -0400)]
wt-status: don't flush before running "submodule status"

This is a holdover from the original implementation in
ac8d5af (builtin-status: submodule summary support,
2008-04-12), which just had the sub-process output to our
descriptor; we had to make sure we had flushed any data that
we produced before it started writing.

Since 3ba7407 (submodule summary: ignore --for-status
option, 2013-09-06), however, we pipe the sub-process output
back to ourselves. So there's no longer any need to flush
(it does not hurt, but it may leave readers wondering why we
do it).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot6039: fix broken && chain
Torsten Bögershausen [Sat, 21 Mar 2015 21:40:02 +0000 (22:40 +0100)]
t6039: fix broken && chain

Add missing &&, detected by the --chain-lint option

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoread-cache: fix reading of split index
Thomas Gummerer [Fri, 20 Mar 2015 21:43:14 +0000 (22:43 +0100)]
read-cache: fix reading of split index

The split index extension uses ewah bitmaps to mark index entries as
deleted, instead of removing them from the index directly.  This can
result in an on-disk index, in which entries of stage #0 and higher
stages appear, which are removed later when the index bases are merged.

15999d0 read_index_from(): catch out of order entries when reading an
index file introduces a check which checks if the entries are in order
after each index entry is read in do_read_index.  This check may however
fail when a split index is read.

Fix this by moving checking the index after we know there is no split
index or after the split index bases are successfully merged instead.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoPost 2.3 cycle (batch #11)
Junio C Hamano [Fri, 20 Mar 2015 20:31:53 +0000 (13:31 -0700)]
Post 2.3 cycle (batch #11)

Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoMerge branch 'mg/log-decorate-HEAD'
Junio C Hamano [Fri, 20 Mar 2015 20:51:24 +0000 (13:51 -0700)]
Merge branch 'mg/log-decorate-HEAD'

Output from "git log --decorate" mentions HEAD when it points at a
tip of an branch differently from a detached HEAD.

This is a potentially backward-incompatible change.

* mg/log-decorate-HEAD:
  log: decorate HEAD with branch name

6 years agoMerge branch 'jc/decorate-leaky-separator-color'
Junio C Hamano [Fri, 20 Mar 2015 20:50:51 +0000 (13:50 -0700)]
Merge branch 'jc/decorate-leaky-separator-color'

"git log --decorate" did not reset colors correctly around the
branch names.

* jc/decorate-leaky-separator-color:
  log --decorate: do not leak "commit" color into the next item
  Documentation/config.txt: simplify boolean description in the syntax section
  Documentation/config.txt: describe 'color' value type in the "Values" section
  Documentation/config.txt: have a separate "Values" section
  Documentation/config.txt: describe the structure first and then meaning
  Documentation/config.txt: explain multi-valued variables once
  Documentation/config.txt: avoid unnecessary negation

6 years agoMerge branch 'sb/leaks'
Junio C Hamano [Fri, 20 Mar 2015 20:11:53 +0000 (13:11 -0700)]
Merge branch 'sb/leaks'

Code cleanup.

* sb/leaks:
  builtin/help.c: fix memory leak
  bundle.c: fix memory leak
  connect.c: do not leak "conn" after showing diagnosis

6 years agoMerge branch 'rs/use-isxdigit'
Junio C Hamano [Fri, 20 Mar 2015 20:11:52 +0000 (13:11 -0700)]
Merge branch 'rs/use-isxdigit'

Code cleanup.

* rs/use-isxdigit:
  use isxdigit() for checking if a character is a hexadecimal digit

6 years agoMerge branch 'mg/verify-commit'
Junio C Hamano [Fri, 20 Mar 2015 20:11:51 +0000 (13:11 -0700)]
Merge branch 'mg/verify-commit'

Workarounds for certain build of GPG that triggered false breakage
in a test.

* mg/verify-commit:
  t7510: do not fail when gpg warns about insecure memory

6 years agoMerge branch 'km/imap-send-libcurl-options'
Junio C Hamano [Fri, 20 Mar 2015 20:11:50 +0000 (13:11 -0700)]
Merge branch 'km/imap-send-libcurl-options'

"git imap-send" learned to optionally talk with an IMAP server via
libcURL; because there is no other option when Git is built with
NO_OPENSSL option, use that codepath by default under such
configuration.

* km/imap-send-libcurl-options:
  imap-send: use cURL automatically when NO_OPENSSL defined

6 years agoMerge branch 'km/bsd-sysctl'
Junio C Hamano [Fri, 20 Mar 2015 20:11:49 +0000 (13:11 -0700)]
Merge branch 'km/bsd-sysctl'

We now detect number of CPUs on older BSD-derived systems.

* km/bsd-sysctl:
  thread-utils.c: detect CPU count on older BSD-like systems
  configure: support HAVE_BSD_SYSCTL option

6 years agoMerge branch 'km/bsd-shells'
Junio C Hamano [Fri, 20 Mar 2015 20:11:48 +0000 (13:11 -0700)]
Merge branch 'km/bsd-shells'

Portability fixes and workarounds for shell scripts have been added
to help BSD-derived systems.

* km/bsd-shells:
  t5528: do not fail with FreeBSD shell
  help.c: use SHELL_PATH instead of hard-coded "/bin/sh"
  git-compat-util.h: move SHELL_PATH default into header
  git-instaweb: use @SHELL_PATH@ instead of /bin/sh
  git-instaweb: allow running in a working tree subdirectory

6 years agoMerge branch 'rs/daemon-hostname-in-strbuf'
Junio C Hamano [Fri, 20 Mar 2015 20:11:47 +0000 (13:11 -0700)]
Merge branch 'rs/daemon-hostname-in-strbuf'

Code in "git daemon" to parse out and hold hostnames used in
request interpolation has been simplified.

* rs/daemon-hostname-in-strbuf:
  daemon: deglobalize hostname information
  daemon: use strbuf for hostname info

6 years agoMerge branch 'mg/detached-head-report'
Junio C Hamano [Fri, 20 Mar 2015 20:11:46 +0000 (13:11 -0700)]
Merge branch 'mg/detached-head-report'

"git branch" on a detached HEAD always said "(detached from xyz)",
even when "git status" would report "detached at xyz".  The HEAD is
actually at xyz and haven't been moved since it was detached in
such a case, but the user cannot read what the current value of
HEAD is when "detached from" is used.

* mg/detached-head-report:
  branch: name detached HEAD analogous to status
  wt-status: refactor detached HEAD analysis

6 years agoMerge branch 'kn/git-cd-to-empty'
Junio C Hamano [Fri, 20 Mar 2015 20:11:46 +0000 (13:11 -0700)]
Merge branch 'kn/git-cd-to-empty'

"git -C '' subcmd" refused to work in the current directory, unlike
"cd ''" which silently behaves as a no-op.

* kn/git-cd-to-empty:
  git: treat "git -C '<path>'" as a no-op when <path> is empty

6 years agoMerge branch 'nd/versioncmp-prereleases'
Junio C Hamano [Fri, 20 Mar 2015 20:11:45 +0000 (13:11 -0700)]
Merge branch 'nd/versioncmp-prereleases'

The versionsort.prerelease configuration variable can be used to
specify that v1.0-pre1 comes before v1.0.

* nd/versioncmp-prereleases:
  config.txt: update versioncmp.prereleaseSuffix
  versionsort: support reorder prerelease suffixes

6 years agorefs.c: drop curate_packed_refs
Jeff King [Fri, 20 Mar 2015 18:43:17 +0000 (14:43 -0400)]
refs.c: drop curate_packed_refs

When we delete a ref, we have to rewrite the entire
packed-refs file. We take this opportunity to "curate" the
packed-refs file and drop any entries that are crufty or
broken.

Dropping broken entries (e.g., with bogus names, or ones
that point to missing objects) is actively a bad idea, as it
means that we lose any notion that the data was there in the
first place. Aside from the general hackiness that we might
lose any information about ref "foo" while deleting an
unrelated ref "bar", this may seriously hamper any attempts
by the user at recovering from the corruption in "foo".

They will lose the sha1 and name of "foo"; the exact pointer
may still be useful even if they recover missing objects
from a different copy of the repository. But worse, once the
ref is gone, there is no trace of the corruption. A
follow-up "git prune" may delete objects, even though it
would otherwise bail when seeing corruption.

We could just drop the "broken" bits from
curate_packed_refs, and continue to drop the "crufty" bits:
refs whose loose counterpart exists in the filesystem. This
is not wrong to do, and it does have the advantage that we
may write out a slightly smaller packed-refs file. But it
has two disadvantages:

  1. It is a potential source of races or mistakes with
     respect to these refs that are otherwise unrelated to
     the operation. To my knowledge, there aren't any active
     problems in this area, but it seems like an unnecessary
     risk.

  2. We have to spend time looking up the matching loose
     refs for every item in the packed-refs file. If you
     have a large number of packed refs that do not change,
     that outweighs the benefit from writing out a smaller
     packed-refs file (it doesn't get smaller, and you do a
     bunch of directory traversal to find that out).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agorepack: turn on "ref paranoia" when doing a destructive repack
Jeff King [Fri, 20 Mar 2015 18:43:13 +0000 (14:43 -0400)]
repack: turn on "ref paranoia" when doing a destructive repack

If we are repacking with "-ad", we will drop any unreachable
objects. Likewise, using "-Ad --unpack-unreachable=<time>"
will drop any old, unreachable objects. In these cases, we
want to make sure the reachability we compute with "--all"
is complete. We can do this by passing GIT_REF_PARANOIA=1 in
the environment to pack-objects.

Note that "-Ad" is safe already, because it only loosens
unreachable objects. It is up to "git prune" to avoid
deleting them.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agoprune: turn on ref_paranoia flag
Jeff King [Fri, 20 Mar 2015 18:43:09 +0000 (14:43 -0400)]
prune: turn on ref_paranoia flag

Prune should know about broken objects at the tips of refs,
so that we can feed them to our traversal rather than
ignoring them. It's better for us to abort the operation on
the broken object than it is to start deleting objects with
an incomplete view of the reachability namespace.

Note that for missing objects, aborting is the best we can
do. For a badly-named ref, we technically could use its sha1
as a reachability tip. However, the iteration code just
feeds us a null sha1, so there would be a reasonable amount
of code involved to pass down our wishes. It's not really
worth trying to do better, because this is a case that
should happen extremely rarely, and the message we provide:

  fatal: unable to parse object: refs/heads/bogus:name

is probably enough to point the user in the right direction.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agorefs: introduce a "ref paranoia" flag
Jeff King [Fri, 20 Mar 2015 18:43:06 +0000 (14:43 -0400)]
refs: introduce a "ref paranoia" flag

Most operations that iterate over refs are happy to ignore
broken cruft. However, some operations should be performed
with knowledge of these broken refs, because it is better
for the operation to choke on a missing object than it is to
silently pretend that the ref did not exist (e.g., if we are
computing the set of reachable tips in order to prune
objects).

These processes could just call for_each_rawref, except that
ref iteration is often hidden behind other interfaces. For
instance, for a destructive "repack -ad", we would have to
inform "pack-objects" that we are destructive, and then it
would in turn have to tell the revision code that our
"--all" should include broken refs.

It's much simpler to just set a global for "dangerous"
operations that includes broken refs in all iterations.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot5312: test object deletion code paths in a corrupted repository
Jeff King [Fri, 20 Mar 2015 18:43:02 +0000 (14:43 -0400)]
t5312: test object deletion code paths in a corrupted repository

When we are doing a destructive operation like "git prune",
we want to be extra careful that the set of reachable tips
we compute is valid. If there is any corruption or oddity,
we are better off aborting the operation and letting the
user figure things out rather than plowing ahead and
possibly deleting some data that cannot be recovered.

The tests here include:

  1. Pruning objects mentioned only be refs with invalid
     names. This used to abort prior to d0f810f (refs.c:
     allow listing and deleting badly named refs,
     2014-09-03), but since then we silently ignore the tip.

     Likewise, we test repacking that can drop objects
     (either "-ad", which drops anything unreachable,
     or "-Ad --unpack-unreachable=<time>", which tries to
     optimize out a loose object write that would be
     directly pruned).

  2. Pruning objects when some refs point to missing
     objects. We don't know whether any dangling objects
     would have been reachable from the missing objects. We
     are better to keep them around, as they are better than
     nothing for helping the user recover history.

  3. Packed refs that point to missing objects can sometimes
     be dropped. By itself, this is more of an annoyance
     (you do not have the object anyway; even if you can
     recover it from elsewhere, all you are losing is a
     placeholder for your state at the time of corruption).
     But coupled with (2), if we drop the ref and then go
     on to prune, we may lose unrecoverable objects.

Note that we use test_might_fail for some of the operations.
In some cases, it would be appropriate to abort the
operation, and in others, it might be acceptable to continue
but taking the information into account. The tests don't
care either way, and check only for data loss.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot1700: make test pass with index-v4
Thomas Gummerer [Fri, 20 Mar 2015 18:20:30 +0000 (19:20 +0100)]
t1700: make test pass with index-v4

The different index versions have different sha-1 checksums.  Those
checksums are checked in t1700, which makes it fail when the test suite
is run with TEST_GIT_INDEX_VERSION=4.  Fix it.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot9158, t9161: fix broken &&-chain in git-svn tests
Michael J Gruber [Fri, 20 Mar 2015 14:32:55 +0000 (15:32 +0100)]
t9158, t9161: fix broken &&-chain in git-svn tests

All of these cases are moderate since they would most probably not
lead to missed failing tests; either they would fail otherwise, or
fail a rm in test_when_finished only.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot9104: fix test for following larger parents
Michael J Gruber [Fri, 20 Mar 2015 14:32:56 +0000 (15:32 +0100)]
t9104: fix test for following larger parents

This test is special for several reasons:
It ends with a "true" statement, which should be a no-op.
It is not because the &&-chain is broken right before it.

Also, looking at what the test intended to test according to
7f578c5 (git-svn: --follow-parent now works on sub-directories of larger
branches, 2007-01-24)
it is not clear how it would achieve that with the given steps.

Amend the test to include the second svn id to be tested for, and
change the tested refs to the ones which are to be expected, and which
make the test pass.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot4104: drop hand-rolled error reporting
Jeff King [Fri, 20 Mar 2015 10:13:36 +0000 (06:13 -0400)]
t4104: drop hand-rolled error reporting

This use of "||" fools --chain-lint into thinking the
&&-chain is broken (and indeed, it is somewhat broken; a
failure of update-index in these tests would show the patch
file, even if we never got to the part of the test where we
fed the patch to git-apply).

The extra blocks were there to include more debugging
output, but it hardly seems worth it; the user should know
which command failed (because git-apply will produce error
messages) and can look in the trash directory themselves.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot0005: fix broken &&-chains
Jeff King [Fri, 20 Mar 2015 10:13:32 +0000 (06:13 -0400)]
t0005: fix broken &&-chains

The ":" noop command always returns true, so it is fine to
include these lines in an &&-chain (and it appeases
--chain-lint).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot7004: fix embedded single-quotes
Jeff King [Fri, 20 Mar 2015 10:13:29 +0000 (06:13 -0400)]
t7004: fix embedded single-quotes

This test uses single quotes inside the single-quoted test
snippet, which effectively makes the contents unquoted.
Since they don't need quoted anyway, this isn't a problem,
but let's switch them to double-quotes to make it more
obviously correct.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot0050: appease --chain-lint
Jeff King [Fri, 20 Mar 2015 10:13:25 +0000 (06:13 -0400)]
t0050: appease --chain-lint

Some of the symlink tests check an either-or case using the
"||". This is not wrong, but fools --chain-lint into
thinking the &&-chain is broken (in fact, there is no &&
chain here).

We can solve this by wrapping the "||" inside a {} block.
This is a bit more verbose, but this construct is rare, and
the {} block helps call attention to it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot9001: use test_when_finished
Jeff King [Fri, 20 Mar 2015 10:13:22 +0000 (06:13 -0400)]
t9001: use test_when_finished

The confirmation tests in t9001 all save the value of
sendemail.confirm, do something to it, then restore it at
the end, in a way that breaks the &&-chain (they are not
wrong, because they save the $? value, but it fools
--chain-lint).

Instead, they can all use test_when_finished, and we can
even make the code simpler by factoring out the shared
lines.

Note that we can _almost_ use test_config here, except that:

  1. We do not restore the config with test_unconfig, but by
     setting it back to some prior value.

  2. We are not always setting a config variable. Sometimes
     the change to be undone is unsetting it entirely.

We could teach test_config to handle these cases, but it's
not worth the complexity for a single call-site.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot4117: use modern test_* helpers
Jeff King [Fri, 20 Mar 2015 10:13:18 +0000 (06:13 -0400)]
t4117: use modern test_* helpers

We can use test_must_fail and test_path_* to avoid some
hand-rolled if statements. This makes the code shorter, and
makes it more obvious when we are breaking the &&-chain.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot6034: use modern test_* helpers
Jeff King [Fri, 20 Mar 2015 10:13:15 +0000 (06:13 -0400)]
t6034: use modern test_* helpers

These say roughly the same thing as the hand-rolled
messages. We do lose the "merge did not complete" debug
message, but merge and write-tree are prefectly capable of
writing useful error messages when they fail.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot1301: use modern test_* helpers
Jeff King [Fri, 20 Mar 2015 10:13:11 +0000 (06:13 -0400)]
t1301: use modern test_* helpers

This shortens the code and fixes some &&-chaining.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot0020: use modern test_* helpers
Jeff King [Fri, 20 Mar 2015 10:13:08 +0000 (06:13 -0400)]
t0020: use modern test_* helpers

This test contains a lot of hand-rolled messages to show
when the test fails. We can omit most of these by using
"verbose" and "test_must_fail". A few of them are for
update-index, but we can assume it produces reasonable error
messages when it fails.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot6030: use modern test_* helpers
Jeff King [Fri, 20 Mar 2015 10:13:05 +0000 (06:13 -0400)]
t6030: use modern test_* helpers

We can get rid of a lot of hand-rolled error messages by
using test_must_fail and test_expect_code. The existing code
was careful to use "|| return 1" when breaking the
&&-chain, but it did fool --chain-lint; the new code is more
idiomatic.

We also add some uses of test_when_finished, which is less
cryptic and more robust than putting code at the end of a
test. In two cases we run "git bisect reset" from a
subshell, which is a problem for test_when_finished (it
would not run). However, in both of these cases, we are
performing the tests in one-off sub-repos, so we do not need
to clean up at all (and in fact it is nicer not to if the
user wants to inspect the trash directory after a failure).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot9502: fix &&-chain breakage
Jeff King [Fri, 20 Mar 2015 10:13:01 +0000 (06:13 -0400)]
t9502: fix &&-chain breakage

This script misses a trivial &&-chain in one of its tests,
but it also has a weird reverse: it includes an &&-chain
outside of any test_expect block! This "cat" should never
fail, but if it did, we would not notice, as it would cause
us to skip the follow-on test entirely (which does not
appear intentional; there are many later tests which rely on
this cat).

Let's instead move the setup into its own test_expect_success
block, which is the standard practice nowadays.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot7201: fix &&-chain breakage
Jeff King [Fri, 20 Mar 2015 10:12:55 +0000 (06:12 -0400)]
t7201: fix &&-chain breakage

One of these breakages is in setup, but one is more severe
and may miss a real test failure. These are pulled out from
the rest, though, because we also clean up a few other
anachronisms. The most interesting is the use of this
here-doc construct:

  (cat >... <<EOF
  ...
  EOF
  ) &&

It looks like an attempt to make the &&-chaining more
natural by letting it come at the end of the here-doc. But
the extra sub-shell is so non-idiomatic (plus the lack of
"<<-") that it ends up confusing.

Since these are just using a single line, we can accomplish
the same thing with a single printf (which also makes the
use of tab more obvious than the verbatim whitespace).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot3600: fix &&-chain breakage for setup commands
Jeff King [Fri, 20 Mar 2015 10:12:51 +0000 (06:12 -0400)]
t3600: fix &&-chain breakage for setup commands

As with the earlier patch to fix "trivial" &&-chain
breakage, these missing "&&" operators are not a serious
problem (e.g., we do not expect "echo" to fail).

Ironically, however, inserting them shows that some of the
commands _do_ fail. Specifically, some of the tests start by
making sure we are at a commit with the string "content" in
the file "foo". However, running "git commit" may fail
because the previous test left us in that state already, and
there is nothing to commit.

We could remove these commands entirely, but they serve to
document the test's assumptions, as well as make it robust
when an earlier test has failed. We could use test_might_fail
to handle all cases, but that would miss an unrelated
failure to make the commit. Instead, we can just pass the
--allow-empty flag to git-commit, which means that it will
not complain if our setup is a noop.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot: avoid using ":" for comments
Jeff King [Fri, 20 Mar 2015 10:12:37 +0000 (06:12 -0400)]
t: avoid using ":" for comments

The ":" is not a comment marker, but rather a noop command.
Using it as a comment like:

  : do something
  cmd1 &&

  : something else
  cmd2

breaks the &&-chain, and we would fail to notice if "cmd1"
failed in this instance. We can just use regular "#"
comments instead.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6 years agot: wrap complicated expect_code users in a block
Jeff King [Fri, 20 Mar 2015 10:12:29 +0000 (06:12 -0400)]
t: wrap complicated expect_code users in a block

If we are expecting a command to produce a particular exit
code, we can use test_expect_code. However, some cases are
more complicated, and want to accept one of a range of exit
codes. For these, we end up with something like:

  cmd;
  case "$?" in
  ...

That unfortunately breaks the &&-chain and fools
--chain-lint. Since these special cases are so few, we can
wrap them in a block, like this:

  { cmd; ret=$?; } &&
  case "$ret" in
  ...

This accomplishes the same thing, and retains the &&-chain
(the exit status fed to the && is that of the assignment,
which should always be true). It's technically longer, but
it is probably a good thing for unusual code like this to
stand out.

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