Once upon a time, git-clone would refuse to write into a
directory that it did not itself create. The cleanup
routines for a failed clone could therefore just remove the
git and worktree dirs completely.

In 55892d2398 (Allow cloning to an existing empty directory,
2009-01-11), we learned to write into an existing directory.
Which means that doing:

  mkdir foo
  git clone will-fail foo

ends up deleting foo. This isn't a huge catastrophe, since
by definition foo must be empty. But it's somewhat
confusing; we should leave the filesystem as we found it.

Because we know that the only directory we'll write into is
an empty one, we can handle this case by just passing the
KEEP_TOPLEVEL flag to our recursive delete (if we could
write into populated directories, we'd have to keep track of
what we wrote and what we did not, which would be much
harder).

Note that we need to handle the work-tree and git-dir
separately, though, as only one might exist (and the new
tests in t5600 cover all cases).

Reported-by: Stephan Janssen <sjanssen@you-get.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Two parts of git-clone's setup logic check whether a
directory exists, and they both call stat directly with the
same scratch "struct stat" buffer. Let's pull that into a
helper, which has a few advantages:

  - it makes the purpose of the stat calls more obvious

  - it makes it clear that we don't care about the
    information in "buf" remaining valid

  - if we later decide to make the check more robust (e.g.,
    complaining about non-directories), we can do it in one
    place

Note that we could just use file_exists() for this, which
has identical code. But we specifically care about
directories, so this future-proofs us against that function
later getting more picky about seeing actual files.

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

This is an old script which could use some updating before
we add to it:

  - use the standard line-breaking:

      test_expect_success 'title' '
              body
      '

  - run all code inside test_expect blocks to catch
    unexpected failures in setup steps

  - use "test_commit -C" instead of manually entering
    sub-repo

  - use test_when_finished for cleanup steps

  - test_path_is_* as appropriate

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

Back when this test was written, git-clone could not handle
a repository without any commits. These days it works fine,
and this comment is out of date.

At first glance it seems like we could just drop this code
entirely now, but it's necessary for the final test, which
was added later. That test corrupts the repository by
temporarily removing its objects, which means we need to
have some objects to move.

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

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

Clarify and enhance documentation for "merge-base --fork-point", as
it was clear what it computed but not why/what for.

* jc/merge-base-fork-point-doc:
  merge-base --fork-point doc: clarify the example and failure modes

A few scripts (both in production and tests) incorrectly redirected
their error output.  These have been corrected.

* tz/redirect-fix:
  rebase: fix stderr redirect in apply_autostash()
  t/lib-gpg: fix gpgconf stderr redirect to /dev/null

"git notes" sent its error message to its standard output stream,
which was corrected.

* tz/notes-error-to-stderr:
  notes: send "Automatic notes merge failed" messages to stderr

The three-way merge performed by "git cherry-pick" was confused
when a new submodule was added in the meantime, which has been
fixed (or "papered over").

* sb/test-cherry-pick-submodule-getting-in-a-way:
  merge-recursive: handle addition of submodule on our side of history
  t/3512: demonstrate unrelated submodule/file conflict as cherry-pick failure

The sequencer machinery (used by "git cherry-pick A..B", and "git
rebase -i", among other things) would have lost a commit if stopped
due to an unlockable index file, which has been fixed.

* pw/sequencer-recover-from-unlockable-index:
  sequencer: reschedule pick if index can't be locked