Git pull: pre-clone backup silently drops .storage/ and other hidden files on first run

[brnl]

Describe the issue you are experiencing

On the first run of the Git pull app (when /config isn't a git
repository yet), the pre-clone backup step silently drops all hidden
files and directories — most importantly .storage/, which holds
auth/refresh tokens, the entity/device/area registries, and any
Lovelace dashboards or helpers created through the UI.

run.sh's pre-clone backup does:

cp -rf /config/* "${BACKUP_LOCATION}" || ...

/config/* is a shell glob and does not match dotfiles/dot-directories
(no dotglob set). The very next step,

rm -rf /config/{,.[!.],..?}* || ...

does match dotfiles — so .storage/, .cloud/, .cache/, etc. get
deleted from /config without ever having been copied to
$BACKUP_LOCATION. The later restore step can't bring back what was
never backed up. Result: on a fresh clone into an existing /config,
.storage/ is permanently wiped.

This was reported before in #3547 and believed fixed by #4356 ("Fix
data loss of .storage and unrelated local files on fresh clone"),
whose description says it "Enables dotglob to preserve hidden
directories like .storage/". Looking at the diff that actually
merged, #4356 only fixed the restore-side line (which had a genuine,
separate, and previously completely broken syntax —
cp "${BACKUP_LOCATION}" "!(*.yaml)" — so nothing was restored before
that fix, not even regular files) plus an unrelated OLD_COMMIT
unbound-variable bug. The backup-side line was never touched, so the
dotfile data loss #3547/#4356 describe is still present as of 9.0.1.

I have a fix ready: #4797 (cp -rf /config/. "${BACKUP_LOCATION}/"
instead of the glob — copies directory contents, hidden entries
included, without depending on a shell dotglob/extglob option).

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Which app are you reporting an issue with?

Git pull

What is the version of the app?

9.0.1 (last released version; bug has been present since before 9.0.1 too — see history above)

Steps to reproduce the issue

1. Have an existing /config with a populated .storage/ directory
   (i.e. a real, already-onboarded Home Assistant instance).
2. Install/configure the Git pull app pointing at a git repository,
   on an instance where /config is not yet a git repo (first run).
3. Start the app and let the initial clone complete.
4. Inspect /config/.storage/ afterwards.

System Health information

Not applicable, this is a silent data-loss bug in the app's own backup
logic (see root cause above), not a runtime error, and doesn't depend on
System Health state.

Anything in the Supervisor logs that might be useful for us?

None, the app completes without error; the bug is that it never captures
dotfiles in the backup in the first place, so nothing logs a failure.

Anything in the app logs that might be useful for us?

No, had to restore my backup, sorry.

Additional information

Fix proposed in #4797.
Related history: #3547 (original report), #4356 (partial fix - restore side only, backup side untouched).