{"thread":{"id":"54805","subject":"Single-Branch Clone: Ability to set a branch for tracking (--track, --set-upstream-to) inoptimally relies on whether it's specified in git config as a branch that's fetchable by default, or if still intended/required, git-fetch should do automatically.","startedAt":"2020-12-09T11:24:52Z","lastAt":"2020-12-09T11:24:52Z","messageCount":1,"participants":["Ron"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"411838","messageId":"xoWsK8vD1iBr_SU-gfZyXyXd-wujLXIngtcwq5PJsT12_69lNHV1Q_6pYfkzr7XeRwhfnmg1h9uVwmsBZgVmRIAYGf14m08_i6hluKPK6rQ=@protonmail.com","threadId":"54805","inReplyTo":null,"subject":"Single-Branch Clone: Ability to set a branch for tracking (--track, --set-upstream-to) inoptimally relies on whether it's specified in git config as a branch that's fetchable by default, or if still intended/required, git-fetch should do automatically.","fromName":"Ron","fromEmail":"ronazek@protonmail.com","sentAt":"2020-12-09T11:22:43Z","receivedAt":"2020-12-09T11:24:52Z","isPatch":false,"sender":{"key":"ronazek@protonmail.com","avatar":null},"body":"What did you do before the bug happened? (Steps to reproduce your issue)\n\n$ git clone --single-branch --no-tags --origin upstream https://github.com/microsoft/vscode.git\nReceiving objects: 100% (958326/958326), 287.26 MiB | 12.07 MiB/s, done.\nResolving deltas: 100% (679324/679324), done.\n$ cd vscode\n(master)$ git checkout -b LocalAddNewPipeline --track upstream/add-new-pipeline\nfatal: 'upstream/add-new-pipeline' is not a commit and a branch 'LocalAddNewPipeline' cannot be created from it\n(master)$ git fetch upstream +refs/heads/add-new-pipeline:refs/remotes/upstream/add-new-pipeline -v\nFrom https://github.com/microsoft/vscode\n* [new branch]            add-new-pipeline -> upstream/add-new-pipeline\n(master)$ git branch -a\n* master\nremotes/upstream/HEAD -> upstream/master\nremotes/upstream/add-new-pipeline\nremotes/upstream/master\n(master)$ git checkout -b LocalAddNewPipeline --track upstream/add-new-pipeline\nfatal: Cannot setup tracking information; starting point 'upstream/add-new-pipeline' is not a branch.\n(master)*$ git status\nOn branch master\nYour branch is up to date with 'upstream/master'.\n\nChanges to be committed:\n(use \"git restore --staged <file>...\" to unstage)\nmodified:   .devcontainer/cache/build-cache-image.sh\nmodified:   .devcontainer/devcontainer.json\n..\nmodified:   test/smoke/src/areas/workbench/localization.test.ts\nmodified:   yarn.lock\n\n\nWhat did you expect to happen? (Expected behavior)\n\nThe new branch to be created with the proper tracking information.\n\n\nWhat happened instead? (Actual behavior)\n\nFirstly, tracking information still can't be set even though we apparently successfully fetched and stored the previously uncloned remote tracking branch add-new-pipeline.\n\nAnd secondly, if the tracking branch has any changes in comparison to the current HEAD (master), git-checkout will terminate in a broken unclean way, affecting the worktree and index, writing to it and staging the changes.\n\n\n\nAnything else you want to add:\n\nPoint one: Git-checkout broken termination is repeatable across different repos and in the same one after doing git reset --hard\n\nPoint two: Same error message while using --track with git-branch, but it terminates cleanly, not affecting worktree or index.\n\nPoint three: Even creating just the branch with git-branch, and trying to --set-upstream-to doesn't work either, same error, clean exit.\n\nPoint four: This tracking error only happens when cloning with --single-branch. While the first error about the branch add-new-pipeline not exiting (being a commit (consistency? says \"branch\" in other errors)) is expected when there no information about it anywhere locally except the single default (master) branch in this case. However this now is unexpected because IMO we gave git everything it needs to know to create the tracking information by fetching with a refspec and creating the remote tracking branch, something else is either not being done right under the hood or perhaps git-fetch forgets to do a step that git-clone would do without --single-branch, which --track seem to rely on, why can't it just see and use the remote-tracking branch like git-branch -a -v can.\n\nPoint five: There's a rumor about there being an artificial limitation of not being able to use a branch as a tracking branch if it's not specified in git config --local remote.upstream.fetch, which I tested and it turned out to be exactly how this is worked around, by specifying the remote-tracking branch specific refspec in git config --local remote.upstream.fetch,  isn't this perhasp what git-fetch should actually do as well when trying to get a previously uncloned branch.\n\nPoint six: However instead of rushing and accepting a workaround, I wanted to entertain that this should be considered a bug or a room for improvement, requiring the use of manual config file edits to me doesn't seem like a optimal official normal workflow but as a rather temporary workaround, even tho I'm not new to config file manipulation at all and don't have a personal problem with it, plus considering the further points below why I think this is a sort of artificial limitation that I don't understand the sense of right now.\n\nPoint seven: Tracking information benefits are also used by other git programs, not just git-fetch, so why should the tracking rely on the refspec set in remote.upstream.fetch anyway, we're not even using git-fetch when using --track in the first place already. There could be another parameter for tracking if necessary at all, and git fetch would write it and report about it with a warning.\n\nPoint eight: Git-fetch could later have a message in such --single-branch cases, \"Fetching previously uncloned branch\" or \"Fetching new remote-tracking branch\", and configuring whatever it has to, to make tracking work right, if fetch would still need to be part of this at all.\n\nPoint nine: Though, sorry for not pointing this out earlier, my reason for fetching with refspec was because without it, git-fetch would only fetch into FETCH_HEAD, and trying to use --track in git-checkout would return this error: fatal: ambiguous argument 'upstream/add-new-pipeline': unknown revision or path not in the working tree.\n\nPoint ten: In that case from point nine, one can do a new branch without tracking and do git merge FETCH_HEAD, but then again you can't use --set-upstream-to as mentioned earlier, and you can't use --track FETCH_HEAD either, saying: fatal: Cannot setup tracking information; starting point 'FETCH_HEAD' is not a branch. Even tho FETCH_HEAD has all the info IMO, --track isn't designed to parse it, but it could right, or would still need refspec to avoid potentially guessing anything?\n\nPoint eleven: --single-branch to me does not means as a single branch forever, but only to clone the default branch initially ... the way git-fetch and --track currently behave somehow indicates they weren't intended for the repo to add new previously uncloned branches ... makes me think what really was the intention behind --single-branch in the very beginning, hopefully not like this.\n\nPoint twelve: Side thing, Docs and git messages don't mention the fact that when --track is used in either git-checkout or git-branch it's not just about setting tracking or upstream, but also basing the new local branch on it instead of the HEAD. It should because the \"track\" term it-self does not convey this fact in any way, even tho it's obvious to a seasoned user, but it still fells subtle, you can keep going and not notice the behavior. I guess that's why the --track option is considered critical and we get an appropriately fatal error if we don't specify it. Before I realized this my original idea if it were only about tracking, git-checkout or git-branch could have created the local branch without it and output a warning to set it up later with --set-upstream-to, however that option doesn't have the same convenience setting the worktree to be based off that specified branch(commit), which is why I'm not seeing --track functionality as redundant or \"old\" as I heard others say, however --set-upstream-to correctly shouldn't do that and I think it makes perfect sense the way it works right now.\n\nPoint thirteen: There's only 12 days of Christmas, sorry. Happy holidays :)\n\nPS: There is ofcourse a chance I could have missed or forgot to mention something during this rather exhaustive drilling, hopefully not something otherwise very obvious.\n\n\n[System Info]\ngit version:\ngit version 2.29.2\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 5.4.0-56-generic #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 x86_64\ncompiler info: gnuc: 9.3\nlibc info: glibc: 2.31\n\nSent with ProtonMail Secure Email.\n"}]}