[lmi] Copying a bare git repository

[Greg Chicares]

TL;DR: These two commands:
  git fetch URL
  git fetch URL master:master
have different effects as demonstrated below, but isn't the
'master:master' part implicit, implying identical effects?

I have a bare repository (of proprietary stuff) in an old chroot,
and I want to copy it to a location outside any chroot, whence I
can easily copy or clone into new chroots. But when I clone from
that copy, I get a repository that isn't up to date.

Here's my "global" bare repository, in a convenient directory:

/home/greg[0]$pushd /srv/cache_for_lmi/blessed/proprietary

I thought I could fetch thither from a chroot's bare repository:

/srv/cache_for_lmi/blessed/proprietary[0]$git fetch 
/srv/chroot/bullseye0/opt/lmi/blessed/proprietary
fatal: Couldn't find remote ref HEAD

...but that didn't work, so I fetch from a corresponding non-bare
repository that is fully up to date, which has this:
  63b2f9d4 (HEAD -> master, origin/master) Use an ELF 'test_coding_rules' 
regardless of $LMI_TRIPLET
as its last commit:

/srv/cache_for_lmi/blessed/proprietary[128]$git fetch 
/srv/chroot/bullseye0/opt/lmi/proprietary/
remote: Enumerating objects: 7132, done.
remote: Counting objects: 100% (7132/7132), done.
remote: Compressing objects: 100% (2375/2375), done.
remote: Total 6675 (delta 5968), reused 4971 (delta 4300), pack-reused 0
Receiving objects: 100% (6675/6675), 2.93 MiB | 7.11 MiB/s, done.
Resolving deltas: 100% (5968/5968), completed with 315 local objects.
>From /srv/chroot/bullseye0/opt/lmi/proprietary
 * branch              HEAD       -> FETCH_HEAD

That appeared to succeed, giving 63b2f9d4 as expected:

/srv/cache_for_lmi/blessed/proprietary[0]$cat FETCH_HEAD 
63b2f9d4d55c03a3221fc25a028bb097690e08da                
/srv/chroot/bullseye0/opt/lmi/proprietary

...but when 'lmi_setup_43.sh' copies it into a brand-new chroot:

  # Duplicate proprietary repository (if available).
  # First, copy "blessed" repository (here, 'cp' is sufficient: this
  # bare repository has no references that need to be resolved):
  cd /opt/lmi || { printf 'failed: cd\n'; exit 3; }
  cp --dereference --preserve --recursive /srv/cache_for_lmi/blessed .

...and then clones from that copy...

  # Then create a working copy by cloning the bare repository...
  git clone -b master file:///opt/lmi/blessed/proprietary

...the new working copy is 170 commits in arrears:

/srv/chroot/lmi_bookworm_4/opt/lmi/proprietary[0]#git log -1
commit b12435394717dcd45f37eead944ca82ab2a59812 (HEAD -> master, origin/master)

...as measured by reference to the working copy I've been using
for everyday work:
  git log --oneline b1243539..HEAD |wc -l
  170

Going back to my "global" bare repository, I've discovered
an incantation that seems to make everything "just work":

/srv/cache_for_lmi/blessed/proprietary[0]$git --no-pager log -1 --oneline 
master 
b1243539 (master) Replace glosses with comments
/srv/cache_for_lmi/blessed/proprietary[0]$git fetch 
/srv/chroot/bullseye0/opt/lmi/proprietary/ master:master 
>From /srv/chroot/bullseye0/opt/lmi/proprietary
   b1243539..63b2f9d4  master     -> master
/srv/cache_for_lmi/blessed/proprietary[0]$git --no-pager log -1 --oneline master
63b2f9d4 (master) Use an ELF 'test_coding_rules' regardless of $LMI_TRIPLET

Thus, I have two commands:

/srv/cache_for_lmi/blessed/proprietary[0]$git fetch 
/srv/chroot/bullseye0/opt/lmi/proprietary/
/srv/cache_for_lmi/blessed/proprietary[0]$git fetch 
/srv/chroot/bullseye0/opt/lmi/proprietary/ master:master

which I thought meant the same thing, but only the second "works". Why?