lock_packed_refs: pass error message back through a strbuf

This saves us from having to be careful about preserving errno and
makes it more explicit in the die-on-error case that the caller is
exiting without a chance to clean up.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
lockfile: introduce flag for locks outside .git

When the lockfile API was introduced, it was only used for the index
file and error messages like

  fatal: Unable to create '/path/to/foo.lock': File exists.

  If no other git process is currently running, this probably means a
  git process crashed in this repository earlier. Make sure no other git
  process is running and remove the file manually to continue.

were appropriate advice for that case.

Nowadays, the lockfile API is used for other files that need similar
lock-then-update semantics, including files not associated to any
repository, such as /etc/gitconfig, ../my.bundle, and /tmp/temp.marks.
Add a flag that makes the message stop referring to "this repository"
for such cases.

This should make it possible to print nicer error messages from
such non-core users of the lockfile API.

This introduces the flag.  Later patches will use it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fast-import: use message from lockfile API when writing marks fails

The usual way to handle errors from hold_lock_file_for_update is to
get a message from unable_to_lock_message or unable_to_lock_die, which
can explain to the user how to check for other git processes running
concurrently and unlink the .lock file if safe.

fast-import didn't use the unable_to_lock_message helper because at
the time it started using the lockfile API (v1.5.1-rc1~69^2~2,
2007-03-07) that helper didn't exist.  Later it still was not
appropriate to use that helper because the message assumed the file
being locked was inside a git repository.  Now there is a flag to
indicate that this lockfile is not part of the repository, so we can
finally use the helper.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
credentials: use message from lockfile API when locking ~/.git-credentials fails

If writing $HOME/.git-credentials.lock (or locking another file
specified with the --file option) fails due to the lock file already
existing, chances are that it is because another git process already
locked the file.  Use the message from the lockfile API that says so,
to help the user to look for running git processes and remove the
stray .lock file when it is safe.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
config: use message from lockfile API when locking config file fails

The message from the lockfile API includes advice about how to remove
a stale lock file after a previous git process crashed.

Pass the LOCK_OUTSIDE_REPOSITORY flag to avoid confusing error
messages that imply the lockfile is under .git.  These functions (and
'git config --file') are useful for arbitrary files in git config
format, including both files outside .git such as /etc/gitconfig and
$XDG_CONFIG_HOME/git/config and files under .git such as
$GIT_DIR/config.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rerere: error out on autoupdate failure

We have been silently tolerating errors by returning early with an
error that the caller ignores since rerere.autoupdate was introduced
in v1.6.0-rc0~120^2 (2008-06-22).  So on error (for example if the
index is already locked), rerere can return success silently without
updating the index or with only some items in the index updated.

Better to treat such failures as a fatal error so the operator can
figure out what is wrong and fix it.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SQUASH???
hold_locked_index: pass error message back through a strbuf

Today hold_locked_index takes a boolean parameter indicating whether
to die with a message or to return -1 with errno indicating the nature
of the problem on error.

Pass back an error message through an 'err' parameter instead.  This
method of error reporting was introduced in the ref transaction API
and makes it more obvious when callers are not reporting errors (for
example, this helped catch rerere.autoupdate skipping the autoupdate
when unable to lock the index).

It also makes it easier for callers to clean up before exiting instead
of having to die() right away and paves the way for simplifying
hold_lock_file_for_update error handling in a later patch.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
hold_lock_file_for_update: pass error message back through a strbuf

This makes it more obvious when callers forget to print a message on
error, while still giving callers a chance to clean up before exiting.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SQUASH???
lockfile: remove unused function 'unable_to_lock_die'

The old callers now use the message passed back by
hold_lock_file_for_update / hold_lock_file_for_append instead of
trying to interpret errno.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
lockfile: make 'unable_to_lock_message' private

The old external callers now use the message passed back by
hold_lock_file_for_update / hold_lock_file_for_append instead of
trying to interpret errno.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>