Merge branch 'ps/not-so-many-refs-are-special'

Define "special ref" as a very narrow set that consists of
FETCH_HEAD and MERGE_HEAD, and clarify everything else that used to
be classified as such are actually just pseudorefs.

* ps/not-so-many-refs-are-special:
  Documentation: add "special refs" to the glossary
  refs: redefine special refs
  refs: convert MERGE_AUTOSTASH to become a normal pseudo-ref
  sequencer: introduce functions to handle autostashes via refs
  refs: convert AUTO_MERGE to become a normal pseudo-ref
  sequencer: delete REBASE_HEAD in correct repo when picking commits
  sequencer: clean up pseudo refs with REF_NO_DEREF

diff --combined refs.c
index c4a1a8c8c1082fe9a4dc2ab121b59dc08f7d8440,08a900a04736b23189f30d63d04d4b0d171d1c6d..c633abf2847cf1b05eec9c9b4d0c817cf78618b6
--- 1/refs.c
--- 2/refs.c
+++ b/refs.c
@@@ -1839,13 -1839,10 +1839,10 @@@ done
  static int is_special_ref(const char *refname)
  {
        /*
-        * Special references get written and read directly via the filesystem
-        * by the subsystems that create them. Thus, they must not go through
-        * the reference backend but must instead be read directly. It is
-        * arguable whether this behaviour is sensible, or whether it's simply
-        * a leaky abstraction enabled by us only having a single reference
-        * backend implementation. But at least for a subset of references it
-        * indeed does make sense to treat them specially:
+        * Special references are refs that have different semantics compared
+        * to "normal" refs. These refs can thus not be stored in the ref
+        * backend, but must always be accessed via the filesystem. The
+        * following refs are special:
         *
         * - FETCH_HEAD may contain multiple object IDs, and each one of them
         *   carries additional metadata like where it came from.
@@@ -1853,30 -1850,12 +1850,12 @@@
         * - MERGE_HEAD may contain multiple object IDs when merging multiple
         *   heads.
         *
-        * There are some exceptions that you might expect to see on this list
-        * but which are handled exclusively via the reference backend:
-        *
-        * - BISECT_EXPECTED_REV
-        *
-        * - CHERRY_PICK_HEAD
-        *
-        * - HEAD
-        *
-        * - ORIG_HEAD
-        *
-        * - "rebase-apply/" and "rebase-merge/" contain all of the state for
-        *   rebases, including some reference-like files. These are
-        *   exclusively read and written via the filesystem and never go
-        *   through the refdb.
-        *
-        * Writing or deleting references must consistently go either through
-        * the filesystem (special refs) or through the reference backend
-        * (normal ones).
+        * Reading, writing or deleting references must consistently go either
+        * through the filesystem (special refs) or through the reference
+        * backend (normal ones).
         */
        static const char * const special_refs[] = {
-               "AUTO_MERGE",
                "FETCH_HEAD",
-               "MERGE_AUTOSTASH",
                "MERGE_HEAD",
        };
        size_t i;
@@@ -1997,9 -1976,11 +1976,9 @@@ const char *refs_resolve_ref_unsafe(str
  }
  
  /* backend functions */
 -int refs_init_db(struct strbuf *err)
 +int refs_init_db(struct ref_store *refs, int flags, struct strbuf *err)
  {
 -      struct ref_store *refs = get_main_ref_store(the_repository);
 -
 -      return refs->be->init_db(refs, err);
 +      return refs->be->init_db(refs, flags, err);
  }
  
  const char *resolve_ref_unsafe(const char *refname, int resolve_flags,