That's a weird workflow, and not really useful in general. Its main feature is using a peculiar reference namespace, treating refs/data/val as if it were a branch name.

The effect is like cloning with --single-branch, except that instead he clones with no branch, then treats the funny ref as if it were a branch.

The git checkout step produces a detached HEAD.

The subsequent commit makes a new commit that extends the detached HEAD.

The final git push updates the other Git, continuing to treat the peculiarly named reference as a branch. The other Git is free to reject the push. Many/most would do simply because refs/data/ is not a known-to-be-safe namespace for pushes.

Since there is no named remote, the remote's branch-names cannot be stored locally for convenience in merging and/or rebasing. Since there are no named branches, Git's built-in branch behavior cannot be used for convenience in committing, merging, and/or rebasing. Since there are neither named branches, nor a named remote, Git's built-in push behavior cannot be used, requiring the fully-spelled-out URL and HEAD-to-ref push.