> Is the last sentence correct? > > $ cd /var/tmp/playpen > $ git clone https://github.com/git/git src > $ git clone --no-local --bare src dst > $ cd src > $ git checkout -b alter > $ git commit -m 'empty' --allow-empty > $ git -c push.default=simple push ../dst > Enumerating objects: 1, done. > Counting objects: 100% (1/1), done. > Writing objects: 100% (1/1), 185 bytes | 92.00 KiB/s, done. > Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0) > To ../dst > * [new branch] alter -> alter > > In "src" repository that is a fresh clone without any customization, > the current branch "alter" does not have any configured upstream. > > Puzzled.... It looks like Git behaves differently depending on whether the remote being pushed to is named "origin" or not: in this example the push fails to "origin" but succeeds to a differently named remote. $ git clone https://github.com/jvns/vue3-tiny-template src $ cd src $ git remote add origin2 https://github.com/jvns/vue3-tiny-template $ git checkout -b alter $ git -c push.default=simple push origin --dry-run fatal: The current branch alter has no upstream branch. $ git -c push.default=simple push origin2 --dry-run To github.com:jvns/vue3-tiny-template * [new branch] alter -> alter I tried to find the responsible code by adding some debug print statements (in this commit: https://github.com/git/git/commit/541e5d7cf61f970a5653ab496e5c3111271654a1) It looks like push.simple has some kind of "same remote" checking, and if the branch has no tracking information, then origin is considered to be the "same remote" (so pushing is not allowed), but origin2 is not the "same remote", so it is allowed
