Revert "Merge branch 'wt/doc-submodule-name-path-confusion-2'"

This reverts commit 00d4ff1a69883e24b095f45251d99143b5bc0320, reversing
changes made to d3badc6eb0961382788c2670129d5ee133d079fd.
t3204: test deleting references when lock files already exist

When deleting a reference, it might be that another process already
holds the lock on the loose reference file and/or the packed-refs
file.  In those cases, there is no alternative but for the delete to
fail.  Verify that in such cases the reference values are left
unchanged.

But in fact, when the packed-refs file lock cannot be acquired, the
loose reference file is deleted anyway, potentially leaving the
reference with a changed value (its packed value, which might even
point at an object that has been garbage collected).  Thus one of the
new tests is marked test_expect_failure.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
try_merge_strategy(): remove redundant lock_file allocation

By the time the "if" block is entered, the lock_file instance from the
main function block is no longer in use, so re-use that one instead of
allocating a second one.

Note that the "lock" variable in the "if" block used to shadow the
"lock" variable at function scope, so the only change needed is to
remove the inner definition.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rollback_lock_file(): do not clear filename redundantly

It is only necessary to clear the lock_file's filename field if it was
not already clear.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rollback_lock_file(): set fd to -1

When rolling back the lockfile, call close_lock_file() so that the
lock_file's fd field gets set back to -1.  This could help prevent
confusion in the face of hypothetical future programming errors.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
lockfile: unlock file if lockfile permissions cannot be adjusted

If the call to adjust_shared_perm() fails, lock_file returns -1, which
to the caller looks like any other failure to lock the file.  So in
this case, roll back the lockfile before returning so that the lock
file is deleted immediately and the lockfile object is left in a
predictable state that (namely, unlocked).  Previously, the lockfile
was retained until process cleanup in this situation.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
hold_lock_file_for_append(): release lock on errors

If there is an error copying the old contents to the lockfile, roll
back the lockfile before exiting so that the lockfile is not held
until process cleanup.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
lock_file(): always add lock_file object to lock_file_list

It used to be that if locking failed, lock_file() usually did not
register the lock_file object in lock_file_list but sometimes it did.
This confusion was compounded if lock_file() was called via
hold_lock_file_for_append(), which has its own failure modes.

The ambiguity didn't have any ill effects, because lock_file objects
cannot be removed from the lock_file_list anyway.  But it is
unnecessary to leave this behavior inconsistent.

So change lock_file() to *always* ensure that the lock_file object is
registered in lock_file_list regardless of whether an error occurs.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
struct lock_file: replace on_list field with flags field

This makes space for other bits.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
api-lockfile: expand the documentation

Document a couple more functions and the flags argument as used by
hold_lock_file_for_update() and hold_lock_file_for_append().

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
lockfile.c: document the various states of lock_file objects

Document the valid states of lock_file objects, how they get into each
state, and how the state is encoded in the object's fields.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
lockfile: define a constant LOCK_SUFFIX_LEN

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
delete_ref_loose(): don't muck around in the lock_file's filename

It's bad manners.  Especially since, if unlink_or_warn() failed, the
memory wasn't restored to its original contents.

So make our own copy to work with.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
config: change write_error() to take a (struct lock_file *) argument

Reduce the amount of code that has to know about the lock_file's
filename field.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
lockfile: use strbufs when handling (most) paths

Change struct lock_file's filename field from a fixed-length buffer
into a strbuf.  This:

* Make buffer overflows a bit less likely

* Removes arbitrary limitations on the length of the path in some
  places, though the restrictions still have to be removed from other
  places to make a real difference

* Shortens the code

Name the new strbuf field lock_filename to make it clear that it
contains the name of the lockfile as opposed to the name of the file
being locked.  Initialize the strbuf the first time the lock_file
object is used.

Change resolve_symlink() to work on a strbuf.

Replace last_path_elm() with a new function, trim_last_path_elm(),
which operates on a strbuf.

Adjust other places in the code that refer directly to the filename.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
resolve_symlink(): use a strbuf internally

This removes another place where the path name is arbitrarily limited.

This gets rid of a warning

    %s: symlink too long

even though strbuf_readlink() in fact still limits the length of what
it can handle to something like 2*PATH_MAX.  But (1) the limit is now
much longer, and (2) strbuf_readlink() doesn't return enough
information to distinguish this problem from other symlink-reading
problems, so just let it go.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit_lock_file(): don't work with a fixed-length buffer

Allocate temporary space to hold result_file instead of storing it in
a fixed-length buffer.  This removes the last arbitrary path-length
limitation, so remove the path length check in lock_file().

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
lock_file(): exit early if lockfile cannot be opened

This is a bit easier to read than the old version, which nested part
of the non-error code in an "if" block.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
lockfile: also keep track of the filename of the file being locked

This reduces the amount of string editing gyrations and makes it
unnecessary for callers to know how to derive the filename from the
lock_filename.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
struct lock_file: rename lock_filename field to staging_filename

Now that the filename is stored separately, the external users of this
field only use it as the filename to which they are trying to write.
Soon it will not necessarily be the name of the lock file, so rename
the field more generically.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>