bisect: clean flags after checking merge bases

Unless there is a good reason to belieave that a particular
invocation of a get_merge_bases*() is the last one that cares about
the object flags the computation of merge bases leaves on the
objects, the "cleanup" parameter should always be true, and I do not
think there is one in this codepath.

Found by code inspection.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
get_merge_bases(): always clean-up object flags

The callers of get_merge_bases() can choose to leave object flags
used during the merge-base traversal by passing cleanup=0 as a
parameter, but in practice a very few callers can afford to do so
(namely, "git merge-base"), as they need to compute merge base in
preparation for other processing of their own and they need to see
the object without contaminate flags.

Change the function signature of get_merge_bases_many() and
get_merge_bases() to drop the cleanup parameter, so that the
majority of the callers do not have to say ", 1" at the end.

Give a new get_merge_bases_many_dirty() API to support only a few
callers that know they do not need to spend cycles cleaning up the
object flags.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
lockfile.c: store absolute path

Locked paths can be saved in a linked list so that if something wrong
happens, *.lock are removed. For relative paths, this works fine if we
keep cwd the same, which is true 99% of time except:

- update-index and read-tree hold the lock on $GIT_DIR/index really
  early, then later on may call setup_work_tree() to move cwd.

- Suppose a lock is being held (e.g. by "git add") then somewhere
  down the line, somebody calls real_path (e.g. "link_alt_odb_entry"),
  which temporarily moves cwd away and back.

During that time when cwd is moved (either permanently or temporarily)
and we decide to die(), attempts to remove relative *.lock will fail,
and the next operation will complain that some files are still locked.

Avoid this case by turning relative paths to absolute before storing
the path in "filename" field.

Reported-by: Yue Lin Ho <yuelinho777@gmail.com>
Helped-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Adapted-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
docs/credential-store: s/--store/--file/

The option name "--store" was used early in development, but
never even made it into an applied patch, let alone a
released version of git. I forgot to update the matching
documentation at the time, though.

Noticed-by: Jesse Hopkins <jesse.hopkins@lmco.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jk/cache-tree-protect-from-broken-libgit2'

The code to use cache-tree trusted the on-disk data too much
and fell into an infinite loop.

* jk/cache-tree-protect-from-broken-libgit2:
  cache-tree: avoid infinite loop on zero-entry tree
Merge branch 'rs/use-child-process-init-more'

* rs/use-child-process-init-more:
  bundle: split out ref writing from bundle_create
  bundle: split out a helper function to compute and write prerequisites
  bundle: split out a helper function to create pack data
  use child_process_init() to initialize struct child_process variables
Merge branch 'jk/fetch-reflog-df-conflict'

Corner-case bugfixes for "git fetch" around reflog handling.

* jk/fetch-reflog-df-conflict:
  ignore stale directories when checking reflog existence
  fetch: load all default config at startup
Merge branch 'tm/line-log-first-parent'

"git log --first-parent -L..." used to crash.

* tm/line-log-first-parent:
  line-log: fix crash when --first-parent is used
Merge branch 'nd/gitignore-trailing-whitespace'

Documentation update.

* nd/gitignore-trailing-whitespace:
  gitignore.txt: fix spelling of "backslash"
Merge branch 'maint'

* maint:
  docs/credential-store: s/--store/--file/
Merge branch 'nd/lockfile-absolute' into next

The lockfile API can get confused which file to clean up when the
process moved the $cwd after creating a lockfile.

* nd/lockfile-absolute:
  lockfile.c: store absolute path
Merge branch 'jc/merge-bases' into next

* jc/merge-bases:
  get_merge_bases(): always clean-up object flags
  bisect: clean flags after checking merge bases
Merge branch 'master' into next

* master:
  docs/credential-store: s/--store/--file/
upload-archive: restrict remote objects with reachability check

When serving a remote request, git-upload-archive tries to
restrict access to unreachable objects, which matches the
behavior of upload-pack. However, we did so by restricting
the requested tree to "<ref>[:<path>]", because it is fast.
That covers the common cases, but does not allow requesting
items by a specific sha1 (either a tree or a commit sha1).

Instead, let's do the correct-but-slower method of actually
walking back from the tips to see if the requested object is
reachable. The performance impact of this is roughly:

  1. For a recent commit, the speed is about the same (we
     traverse in reverse chronological order, so we see it
     almost immediately).

  2. For an older commit, even one pointed at directly by a
     ref (e.g., an old tag), we are slower, because we
     traverse from the more recent tips. We are bounded in
     this case by the time to look at all commits (i.e.,
     "time git rev-list --all").

  3. When we see "$ref:$path", we typically perform much
     worse, because our traversal looks at all commits
     first, followed by all trees.

  4. The worst case (which we hit for an unreachable object)
     is equivalent to "time rev-list --objects --all", which
     is about the same amount of time pack-objects spends
     preparing a full clone (which can be in the tens of
     seconds for a large repository).

The implementation is a fairly straightforward application
of the traverse_commit_list function. Using the
mark_objects_reachable function would seem more appropriate,
but it has no mechanism for looking for a specific object,
which lets us end the traversal early in common cases.
list-objects: optimize "revs->blob_objects = 0" case

If we are traversing trees during a "--objects"
traversal, we may skip blobs if the "blob_objects" field of
rev_info is not set. But we do so as the first thing in
process_blob(), only after we have actually created the
"struct blob" object, incurring a hash lookup. We can
optimize out this no-op call completely.

This does not actually affect any current code, as all of
the current traversals always set blob_objects when looking
at objects, anyway.
archive: ignore blob objects when checking reachability

We cannot create an archive from a blob object, so we would
not expect anyone to provide one to us. And if they do, we
will fail anyway just after the reachability check.  We can
therefore optimize our reachability check to ignore blobs
completely, and not even create a "struct blob" for them.

Depending on the repository size and the exact place we find
the reachable object in the traversal, this can save 20-25%,
a we can avoid many lookups in the object hash.

The downside of this is that a blob provided to a remote
archive process will fail with "no such object" rather than
"object is not a tree" (we could organize the code to retain
the old message, but since we no longer know whether the
blob is reachable or not, we would potentially be leaking
information about the existence of unreachable objects).
t5000: drop tag to supposedly unreachable object

We try to create an unreachable commit, but test_commit will
retain a tag pointing to it. Oops.
t/perf-lib: factor boilerplate out of test_perf

About half of test_perf() is boilerplate, and half is
actually related to running the perf test. Let's split it
into two functions, so that we can reuse the boilerplate in
future commits.
t/perf/aggregate: factor our percent calculations

This will let us reuse the code when we add new values to
aggregate besides times.
t/perf: add infrastructure for measuring sizes

The main objective of scripts in the perf framework is to
run "test_perf", which measures the time it takes to run
some operation. However, it can also be interesting to see
the change in the output size of certain operations.

This patch introduces test_size, which records a single
numeric output from the test and shows it in the aggregated
output (with pretty printing and relative size comparison).