If we have the same image at foo:bar and example.com/foo:bar and we already have foo:bar locally and then pull example.com/foo:bar, Docker will update RepoDigests for the latter but not the blob mount sources data, so later pushes of images based on foo:bar to example.com will re-upload those layers, even though Docker itself knows they already exist and could/should blob mount them instead.

This shuffles that logic slightly so that they can be registered at the new name too. (This makes an especially large difference for big layers like Windows where re-uploading them is extremely expensive, not to mention unnecessarily potentially changing their registry digest due to recompression.)

My own use case here is that I'm doing docker load on some layers that are already pushed to my target registry, then building new things on top and pushing those to my target registry, and Docker doesn't know that the layers already exist so it's re-pushing them (using tar-split so the diff_ids are the same, but it has to recompress so the actual content digest does change, which is unnecessarily confusing and unnecessarily wasting registry storage). With this change, I can docker load my local copy, then no-op docker pull the remote copy to prime Docker's knowledge of these layers existing so that the docker push of my new images based on them do blob mounts instead of recompressing and repushing! 🥳