When the goal is to wait for some random amount of time up to one
second, it is not necessary to compute with microsecond precision.
This is a preparation to re-use sleep_millisec().
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Reviewed-by: NMichael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We want to use the new function elsewhere in a moment.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Reviewed-by: NMichael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

On Windows, we do not have functions srandom() and random(). Use srand()
and rand(). These functions produce random numbers of lesser quality,
but for the purpose (a retry time-out) they are still good enough.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Reviewed-by: NMichael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently, there is only one attempt to acquire any lockfile, and if
the lock is held by another process, the locking attempt fails
immediately.

This is not such a limitation for loose reference files. First, they
don't take long to rewrite. Second, most reference updates have a
known "old" value, so if another process is updating a reference at
the same moment that we are trying to lock it, then probably the
expected "old" value will not longer be valid, and the update will
fail anyway.

But these arguments do not hold for packed-refs:

* The packed-refs file can be large and take significant time to
  rewrite.

* Many references are stored in a single packed-refs file, so it could
  be that the other process was changing a different reference than
  the one that we are interested in.

Therefore, it is much more likely for there to be spurious lock
conflicts in connection to the packed-refs file, resulting in
unnecessary command failures.

So, if the first attempt to lock the packed-refs file fails, continue
retrying for a configurable length of time before giving up. The
default timeout is 1 second.
Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently, there is only one attempt to lock a file. If it fails, the
whole operation fails.

But it might sometimes be advantageous to try acquiring a file lock a
few times before giving up. So add a new function,
hold_lock_file_for_update_timeout(), that allows a timeout to be
specified. Make hold_lock_file_for_update() a thin wrapper around the
new function.

If timeout_ms is positive, then retry for at least that many
milliseconds to acquire the lock. On each failed attempt, use select()
to wait for a backoff time that increases quadratically (capped at 1
second) and has a random component to prevent two processes from
getting synchronized. If timeout_ms is negative, retry indefinitely.

In a moment we will switch to using the new function when locking
packed-refs.
Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  Git 2.4.1

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

* sb/line-log-plug-pairdiff-leak:
  line-log.c: fix a memleak

* sb/test-bitmap-free-at-end:
  pack-bitmap.c: fix a memleak

Correct test bitrot.

* nd/t1509-chroot-test:
  t1509: update prepare script to be able to run t1509 in chroot again

"git cat-file bl $blob" failed to barf even though there is no
object type that is "bl".

* jk/type-from-string-gently:
  type_from_string_gently: make sure length matches

* ep/fix-test-lib-functions-report:
  test-lib-functions.sh: fix the second argument to some helper functions

Teach the codepaths that read .gitignore and .gitattributes files
that these files encoded in UTF-8 may have UTF-8 BOM marker at the
beginning; this makes it in line with what we do for configuration
files already.

* cn/bom-in-gitignore:
  attr: skip UTF8 BOM at the beginning of the input file
  config: use utf8_bom[] from utf.[ch] in git_parse_source()
  utf8-bom: introduce skip_utf8_bom() helper
  add_excludes_from_file: clarify the bom skipping logic
  dir: allow a BOM at the beginning of exclude files

Access to objects in repositories that borrow from another one on a
slow NFS server unnecessarily got more expensive due to recent code
becoming more cautious in a naive way not to lose objects to pruning.

* jk/prune-mtime:
  sha1_file: only freshen packs once per run
  sha1_file: freshen pack objects before loose
  reachable: only mark local objects as recent

We avoid setting core.worktree when the repository location is the
".git" directory directly at the top level of the working tree, but
the code misdetected the case in which the working tree is at the
root level of the filesystem (which arguably is a silly thing to
do, but still valid).

* jk/init-core-worktree-at-root:
  init: don't set core.worktree when initializing /.git

* maint:
  Git 2.3.8

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

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

Documentation fix.

* mm/usage-log-l-can-take-regex:
  log -L: improve error message on malformed argument
  Documentation: change -L:<regex> to -L:<funcname>

The usual "git diff" when seeing a file turning into a directory
showed a patchset to remove the file and create all files in the
directory, but "git diff --no-index" simply refused to work.  Also,
when asked to compare a file and a directory, imitate POSIX "diff"
and compare the file with the file with the same name in the
directory, instead of refusing to run.

* jc/diff-no-index-d-f:
  diff-no-index: align D/F handling with that of normal Git
  diff-no-index: DWIM "diff D F" into "diff D/F F"

The default $HOME/.gitconfig file created upon "git config --global"
that edits it had incorrectly spelled user.name and user.email
entries in it.

* oh/fix-config-default-user-name-section:
  config: fix settings in default_user_config template

"git commit --date=now" or anything that relies on approxidate lost
the daylight-saving-time offset.

* jc/epochtime-wo-tz:
  parse_date_basic(): let the system handle DST conversion
  parse_date_basic(): return early when given a bogus timestamp

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

Code clean-up for xdg configuration path support.

* pt/xdg-config-path:
  path.c: remove home_config_paths()
  git-config: replace use of home_config_paths()
  git-commit: replace use of home_config_paths()
  credential-store.c: replace home_config_paths() with xdg_config_home()
  dir.c: replace home_config_paths() with xdg_config_home()
  attr.c: replace home_config_paths() with xdg_config_home()
  path.c: implement xdg_config_home()

Catch a programmer mistake to feed a pointer not an array to
ARRAY_SIZE() macro, by using a couple of GCC extensions.

* ep/do-not-feed-a-pointer-to-array-size:
  git-compat-util.h: implement a different ARRAY_SIZE macro for for safely deriving the size of array

"hash-object --literally" introduced in v2.2 was not prepared to
take a really long object type name.

* jc/hash-object:
  write_sha1_file(): do not use a separate sha1[] array
  t1007: add hash-object --literally tests
  hash-object --literally: fix buffer overrun with extra-long object type
  git-hash-object.txt: document --literally option

Code clean-up (not a leak-fix).

* sb/prefix-path-free-results:
  prefix_path(): unconditionally free results in the callers

Code simplification.

* sg/completion-no-redundant-all-command-list:
  completion: remove redundant __git_compute_all_commands() call

The completion for "log --decorate=" parameter value was incorrect.

* sg/complete-decorate-full-not-long:
  completion: fix and update 'git log --decorate=' options

"filter-branch" corrupted commit log message that ends with an
incomplete line on platforms with some "sed" implementations that
munge such a line.  Work it around by avoiding to use "sed".

* jk/filter-branch-use-of-sed-on-incomplete-line:
  filter-branch: avoid passing commit message through sed

"git daemon" fails to build from the source under NO_IPV6
configuration (regression in 2.4).

* jc/daemon-no-ipv6-for-2.4.1:
  daemon: unbreak NO_IPV6 build regression

Some error messages in "git config" were emitted without calling
the usual error() facility.

* jn/clean-use-error-not-fprintf-on-stderr:
  config: use error() instead of fprintf(stderr, ...)

Some time ago, "git blame" (incorrectly) lost the convert_to_git()
call when synthesizing a fake "tip" commit that represents the
state in the working tree, which broke folks who record the history
with LF line ending to make their project portabile across
platforms while terminating lines in their working tree files with
CRLF for their platform.

* tb/blame-resurrect-convert-to-git:
  blame: CRLF in the working tree and LF in the repo

* va/fix-git-p4-tests:
  git-p4: t9814: prevent --chain-lint failure

* ld/p4-case-fold:
  git-p4: add failing tests for case-folding p4d

"git rebase --quiet" was not quite quiet when there is nothing to
do.

* jk/rebase-quiet-noop:
  rebase: silence "git checkout" for noop rebase

git p4 attempts to better handle branches in Perforce.

* va/p4-client-path:
  git-p4: improve client path detection when branches are used
  t9801: check git-p4's branch detection with client spec enabled

When "add--interactive" splits a hunk into two overlapping hunks
and then let the user choose only one, it sometimes feeds an
incorrect patch text to "git apply".  Add tests to demonstrate
this.

I have a slight suspicion that this may be $gmane/87202 coming back
and biting us (I seem to have said "let's run with this and see
what happens" back then).

* mm/add-p-split-error:
  stash -p: demonstrate failure of split with mixed y/n
  t3904-stash-patch: factor PERL prereq at the top of the file
  t3904-stash-patch: fix test description
  add -p: demonstrate failure when running 'edit' after a split
  t3701-add-interactive: simplify code

More line-ending tests.

* tb/t0027-crlf:
  t0027: Add repoMIX and LF_nul
  t0027: support NATIVE_CRLF platforms
  t0027: cleanup: rename functions; avoid non-leading TABs

"git p4" learned "--changes-block-size <n>" to read the changes in
chunks from Perforce, instead of making one call to "p4 changes"
that may trigger "too many rows scanned" error from Perforce.

* ls/p4-changes-block-size:
  git-p4: use -m when running p4 changes