pack-objects: turn off bitmaps when we see --shallow lines

Reachability bitmaps do not work with shallow operations,
because they cache a view of the object reachability that
represents the true objects. Whereas a shallow repository
(or a shallow operation in a repository) is inherently
cutting off the object graph with a graft.

We explicitly disallow the use of bitmaps in shallow
repositories by checking is_repository_shallow(), and we
should continue to do that. However, we also want to
disallow bitmaps when we are serving a fetch to a shallow
client, since we momentarily take on their grafted view of
the world.

It used to be enough to call is_repository_shallow at the
start of pack-objects.  Upload-pack wrote the other side's
shallow state to a temporary file and pointed the whole
pack-objects process at this state with "git --shallow-file",
and from the perspective of pack-objects, we really were
in a shallow repo.  But since b790e0f (upload-pack: send
shallow info over stdin to pack-objects, 2014-03-11), we do
it differently: we send --shallow lines to pack-objects over
stdin, and it registers them itself.

This means that our is_repository_shallow check is way too
early (we have not been told about the shallowness yet), and
that it is insufficient (calling is_repository_shallow is
not enough, as the shallow grafts we register do not change
its return value). Instead, we can just turn off bitmaps
explicitly when we see these lines.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-pack: move REF_STATUS_REJECT_NODELETE logic a bit higher

20e8b465 (refactor ref status logic for pushing, 2010-01-08)
restructured the code to set status for each ref to be pushed, but
did not quite go far enough.  We inspect the status set earlier by
set_refs_status_for_push() and then perform yet another update to
the status of a ref with an otherwise OK status to be deleted to
mark it with REF_STATUS_REJECT_NODELETE when the protocol tells us
never to delete.

Split the latter into a separate loop that comes before we enter the
per-ref loop.  This way we would have one less condition to check in
the main loop.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-pack: refactor decision to send update per ref

A new helper function ref_update_to_be_sent() decides for each ref
if the update is to be sent based on the status previously set by
set_ref_status_for_push() and also if this is a mirrored push.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
unpack-trees: simplify 'all other failures' case

In the 'if (current)' block of twoway_merge, we handle the boring
errors by checking if the entry from the old tree, current index, and
new tree are present, to get a pathname for the error message from one
of them:

	if (oldtree)
		return o->gently ? -1 : reject_merge(oldtree, o);
	if (current)
		return o->gently ? -1 : reject_merge(current, o);
	if (newtree)
		return o->gently ? -1 : reject_merge(newtree, o);
	return -1;

Since this is guarded by 'if (current)', the second test is guaranteed
to succeed.  Moreover, any of the three entries, if present, would
have the same path because there is no rename detection in this code
path.   Even if some day in the future the entries' paths differ, the
'current' path used in the index and worktree would presumably be the
most recognizable for the end user.

Simplify by just using 'current'.

Noticed by coverity, Id:290002

Signed-off-by: Stefan Beller <stefanbeller@gmail.com>
Improved-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
unpack-trees: use 'cuddled' style for if-else cascade

Match the predominant style in git by following K&R style for if/else
cascades.  Documentation/CodingStyle from linux.git explains:

  Note that the closing brace is empty on a line of its own, _except_ in
  the cases where it is followed by a continuation of the same statement,
  ie a "while" in a do-statement or an "else" in an if-statement, like
  this:

	if (x == y) {
		..
	} else if (x > y) {
		...
	} else {
		....
	}

  Rationale: K&R.

  Also, note that this brace-placement also minimizes the number of empty
  (or almost empty) lines, without any loss of readability.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
checkout -m: attempt merge when deletion of path was staged

twoway_merge() is missing an o->gently check in the case where a file
that needs to be modified is missing from the index but present in the
old and new trees.  As a result, in this case 'git checkout -m' errors
out instead of trying to perform a merge.

Fix it by checking o->gently.  While at it, inline the o->gently check
into reject_merge to prevent future call sites from making the same
mistake.

Noticed by code inspection.  The motivating case hasn't been tested.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fast-import.c: replace `git_config()` with `git_config_get_*()` family

Use `git_config_get_*()` family instead of `git_config()` to take
advantage of the config-set API which provides a cleaner control flow.

Signed-off-by: Tanay Abhra <tanayabh@gmail.com>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
ll-merge.c: refactor `read_merge_config()` to use `git_config_string()`

There is one slight behavior change, previously "merge.default"
silently ignored a NULL value and didn't raise any error. But,
in the same function, all other values raise an error on a NULL
value. So to conform with other call sites in Git, a NULL value
for "merge.default" raises an error.

The the new config-set API is not very useful here, because much of
the function is dedicated to processing "merge.<name>.variable",
which the new API does not handle well.  If it were for variables
like, "merge.summary", "merge.tool", and "merge.verbosity", we could
use the new API.

Signed-off-by: Tanay Abhra <tanayabh@gmail.com>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive.c: replace `git_config()` with `git_config_get_int()`

Use `git_config_get_int()` instead of `git_config()` to take advantage
of the config-set API which provides a cleaner control flow.

Signed-off-by: Tanay Abhra <tanayabh@gmail.com>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/apply.c: replace `git_config()` with `git_config_get_string_const()`

Use `git_config_get_string_const()` instead of `git_config()` to take
advantage of the config-set API which provides a cleaner control flow.

Signed-off-by: Tanay Abhra <tanayabh@gmail.com>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SQUASH???
tests: fix negated test_i18ngrep calls

The helper function test_i18ngrep pretends that it found the expected
results when it is running under GETTEXT_POISON. For this reason, it must
not be used negated like so

   ! test_i18ngrep foo bar

because the test case would fail under GETTEXT_POISON. The function offers
a special syntax to test that a pattern is *not* found:

   test_i18ngrep ! foo bar

Convert incorrect uses to this syntax.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
push: the beginning of "signed push"

While signed tags and commits assert that the objects thusly signed
came from you, there is no good way to assert that you wanted to
have a particular object at the tip of a particular branch.

This introduces a skeletal framework to allow you to sign a "push
certificate" (for the lack of better name) every time you push,
asserting that what object you are pushing to update which ref that
used to point at what other object.

Think of it as a cryptographic protection for ref updates, similar
to signed tags/commits but working on an orthogonal axis.

The basic flow based on this idea would go like this:

 1. You push out your work with "git push -s".

 2. The sending side learns where the remote refs are and which refs
    are to be updated with this push, as usual, together with what
    protocol extension the receiving end supports.  If the receiving
    end does not advertise the protocol extension "push-cert", the
    sending side falls back to the normal push that is not signed.

    Otherwise, a text file in core, that looks like the following,
    is prepared:

	pushed-by Junio C Hamano <gitster@pobox.com>
	pushed-at 1315427886 -0700
	update 7339ca65... 21580ecb... refs/heads/master
	update 3793ac56... 12850bec... refs/heads/next

    Each "update" line shows the old and the new object name at the
    tip of the ref this push tries to update, in the way identical
    to how the underlying "git push" protocol exchange tells the ref
    updates to the receiving end.

    The user then is asked to sign this push certificate using GPG
    and the result is carried to the other side (i.e. receive-pack).

    In the protocol exchange, this step comes immediately before the
    sender tells what the result of the push should be, which in
    turn comes before it sends the pack data.

    Because "update" records in a push certificate carry the same
    information as the result packets in the protocol exchange, we
    could probably omit/shorten the latter when a push certificate
    is in use to reduce the protocol overhead.

 3. When the receiving end sees a push certificate, it checks the
    validity of its GPG signature (the receiving end needs to have
    GNUPGHOME configured for this), and makes sure that the signer
    matches the identity recorded on "pushed-by" record, before
    starting to accept the pack data stream.  The push is failed if
    the certificate verification fails.

 4. The pre-receive hook can inspect the push certificate and take
    it into account when it makes the decision to allow or reject
    this push.  In order to make the interface backward compatible,
    receive-pack would write the push certificate to a blob object
    and give its object name in an environment variable of the hook.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'hv/submodule-config' into jch

* hv/submodule-config:
  do not die on error of parsing fetchrecursesubmodules option
  use new config API for worktree configurations of submodules
  extract functions for submodule config set and lookup
  implement submodule config cache for lookup of submodule names
Merge branch 'jc/reopen-lock-file' into jch

Needed in the "commit -p" code path to update the cache tree in the
index (e.g. for dt/cache-tree-repair topic).

* jc/reopen-lock-file:
  lockfile: allow reopening a closed but still locked file
Merge branch 'dt/cache-tree-repair' into jch

Add a few more places in "commit" and "checkout" that make sure
that the cache-tree is fully populated in the index.

* dt/cache-tree-repair:
  cache-tree: Write updated cache-tree after commit
  cache-tree: subdirectory tests
  test-dump-cache-tree: invalid trees are not errors
  cache-tree: create/update cache-tree on checkout

# Conflicts:
# 	builtin/checkout.c
# 	builtin/commit.c
Merge branch 'nd/multiple-work-trees' into jch

A replacement for contrib/workdir/git-new-workdir that does not
rely on symbolic links and make sharing of objects and refs safer
by making the borrowee and borrowers aware of each other.

* nd/multiple-work-trees: (31 commits)
  checkout: don't require a work tree when checking out into a new one
  git_path(): keep "info/sparse-checkout" per work-tree
  count-objects: report unused files in $GIT_DIR/repos/...
  gc: support prune --repos
  gc: factor out gc.pruneexpire parsing code
  gc: style change -- no SP before closing parenthesis
  prune: strategies for linked checkouts
  checkout: detach if the branch is already checked out elsewhere
  checkout: clean up half-prepared directories in --to mode
  checkout: support checking out into a new working directory
  use new wrapper write_file() for simple file writing
  wrapper.c: wrapper to open a file, fprintf then close
  setup.c: support multi-checkout repo setup
  setup.c: detect $GIT_COMMON_DIR check_repository_format_gently()
  setup.c: convert check_repository_format_gently to use strbuf
  setup.c: detect $GIT_COMMON_DIR in is_git_directory()
  setup.c: convert is_git_directory() to use strbuf
  git-stash: avoid hardcoding $GIT_DIR/logs/....
  *.sh: avoid hardcoding $GIT_DIR/hooks/...
  git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects
  ...

# Conflicts:
# 	refs.c
# 	refs.h
# 	trace.c
Merge branch 'rs/strbuf-getcwd' into jch

* rs/strbuf-getcwd:
  use strbuf_add_absolute_path() to add absolute paths
  abspath: convert absolute_path() to strbuf
  use xgetcwd() to set $GIT_DIR
  use xgetcwd() to get the current directory or die
  wrapper: add xgetcwd()
  abspath: convert real_path_internal() to strbuf
  abspath: use strbuf_getcwd() to remember original working directory
  setup: convert setup_git_directory_gently_1 et al. to strbuf
  unix-sockets: use strbuf_getcwd()
  strbuf: add strbuf_getcwd()
Merge branch 'mm/config-edit-global' into jch

Start "git config --edit --global" from a skeletal per-user
configuration file contents, instead of a total blank, when the
user does not already have any.  This immediately reduces the need
for a later "Have you forgotten setting core.user?" and we can add
more to the template as we gain more experience.

* mm/config-edit-global:
  commit: advertise config --global --edit on guessed identity
  home_config_paths(): let the caller ignore xdg path
  config --global --edit: create a template file if needed
Merge branch 'rs/init-no-duplicate-real-path' into jch

* rs/init-no-duplicate-real-path:
  init: avoid superfluous real_path() calls