{"thread":{"id":"56834","subject":"Git Checkout tracking behavior with <start_point>?","startedAt":"2021-11-03T15:08:44Z","lastAt":"2021-11-04T10:17:35Z","messageCount":3,"participants":["Cyrus Vafadari","Stefan Moch","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"440377","messageId":"CAMd+_QCDN5UwwC=ZRcT4Y3p1x7kCQ1TEVf5321Ykx4xrhv-YOA@mail.gmail.com","threadId":"56834","inReplyTo":null,"subject":"Git Checkout tracking behavior with <start_point>?","fromName":"Cyrus Vafadari","fromEmail":"cvafadari@gmail.com","sentAt":"2021-11-03T15:08:29Z","receivedAt":"2021-11-03T15:08:44Z","isPatch":false,"sender":{"key":"cvafadari@gmail.com","avatar":null},"body":"Hello all,\n\nI'm new to this mailing list, so I hope I'm doing it right!\n\nI am an avid user of this pattern: \"git checkout -b my_branch\nupstream/3.2.x\", using \"start_point\" to build my backported patch\nagainst an old feature version. But in this case, the default tracking\nis against 3.2.x, rather than my new feature branch. So, then, when I\npush I specify to update the tracking against the new branch name.\nThere are also various default behaviors for push, which I won't\nenumerate here, but in the end I need to specify tracking.\n\nI'm wondering if there is some usage/pattern I'm missing?\n\nOr is this an opportunity to add a gitconfig for \"tracking behavior\"\nof `checkout` with start_point? If there is agreement that this could\nbe improved with a new config, I'd be happy to open a PR.\n\nBest,\nCyrus\n"},{"id":"440401","messageId":"10455b65-377f-5bd5-fd7e-c6cb44d2f82f@mail.de","threadId":"56834","inReplyTo":"CAMd+_QCDN5UwwC=ZRcT4Y3p1x7kCQ1TEVf5321Ykx4xrhv-YOA@mail.gmail.com","subject":"Re: Git Checkout tracking behavior with <start_point>?","fromName":"Stefan Moch","fromEmail":"stefanmoch@mail.de","sentAt":"2021-11-03T20:17:56Z","receivedAt":"2021-11-03T20:24:44Z","isPatch":false,"sender":{"key":"stefanmoch@mail.de","avatar":null},"body":"Hello Cyrus,\n\nAm 03.11.21 um 16:08 schrieb Cyrus Vafadari:\n> I'm new to this mailing list, so I hope I'm doing it right!\n\nWelcome! And yes.\n\n> I am an avid user of this pattern: \"git checkout -b my_branch\n> upstream/3.2.x\", using \"start_point\" to build my backported patch\n> against an old feature version. But in this case, the default tracking\n> is against 3.2.x, rather than my new feature branch. So, then, when I\n> push I specify to update the tracking against the new branch name.\n> There are also various default behaviors for push, which I won't\n> enumerate here, but in the end I need to specify tracking.\n> \n> I'm wondering if there is some usage/pattern I'm missing?\n> \n> Or is this an opportunity to add a gitconfig for \"tracking behavior\"\n> of `checkout` with start_point? If there is agreement that this could\n> be improved with a new config, I'd be happy to open a PR.\n\nThere is already a --[no-]track option[1] to the commands that\ncreate new branches (switch, branch, checkout, worktree) to toggle\nthis behavior per command invocation, and also the configuration\noption branch.autoSetupMerge[2] to set the desired behavior generally.\n\nExample:\n\n1. check if not set, default behavior / your example\n\n   $ git config branch.autoSetupMerge\n   $ git checkout -b trackingtest_1 origin/master  # like you did\n   Branch 'trackingtest_1' set up to track remote branch 'master'\n   from 'origin'.\n   Switched to a new branch 'trackingtest_1'\n\n   (as you noticed: the start point is set as the new branch's\n   upstream)\n\n2. specify --no-track to prevent tracking branch creation for\n   command:\n\n   $ git checkout --no-track -b trackingtest_2 origin/master\n   Switched to a new branch 'trackingtest_2'\n\n   (no tracking branch created)\n\n3. or, configure the general behavior (test without --no-track\n   again):\n\n   $ git config --local branch.autoSetupMerge false\n   $ git checkout -b trackingtest_3 origin/master\n   Switched to a new branch 'trackingtest_3'\n\n   (no tracking branch created)\n\n4. verify, what we just did:\n\n   $ git branch --list 'trackingtest_*' -vv\n     trackingtest_1 66262451ec [origin/master] Git 2.33-rc0\n     trackingtest_2 66262451ec Git 2.33-rc0\n   * trackingtest_3 66262451ec Git 2.33-rc0\n\n   (only the first one has the remote tracking branch set)\n\n5. to set the new remote tracking branch of the same name (and\n   create it in the remote repository in one step)[3]:\n\n   $ git push -u origin HEAD\n   Branch 'trackingtest_3' set up to track remote branch\n   'trackingtest_3' from 'origin'.\n   Everything up-to-date\n\n\nWhen you create the new branch, this happens only in the local\nrepository – it is therefore a separate step (push) to create the\nbranch in a remote repository. As this normally (without -u) would\nnot change/set the upstream for the branch, this has to be done on\nthe first push with '-u'. Using HEAD as a shortcut, you can push the\ncurrently checked out branch without specifying the branch name[4].\nIf there is already a branch with this name on the remote\nrepository, the push will of course only work for fast-forwards,\nunless forced.\n\nRethinking it: if you are doing the 'git push -u origin HEAD' anyway\n– maybe even as first step after the branch creation –, or you don't\nintent to fetch/pull into this branch before the push, you can\nforego either using --no-track and setting branch.autoSetupMerge.\n\n\n\nStefan\n\n\n[1]\nhttps://git-scm.com/docs/git-checkout#Documentation/git-checkout.txt---track\n[2]\nhttps://git-scm.com/docs/git-config#Documentation/git-config.txt-branchautoSetupMerge\n[3] https://git-scm.com/docs/git-push#Documentation/git-push.txt--u\n[4]\nhttps://git-scm.com/docs/git-push#Documentation/git-push.txt-codegitpushoriginHEADcode\n"},{"id":"440443","messageId":"YYOzPVi5TAoyGNAs@coredump.intra.peff.net","threadId":"56834","inReplyTo":"CAMd+_QCDN5UwwC=ZRcT4Y3p1x7kCQ1TEVf5321Ykx4xrhv-YOA@mail.gmail.com","subject":"Re: Git Checkout tracking behavior with <start_point>?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-04T10:17:33Z","receivedAt":"2021-11-04T10:17:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 03, 2021 at 11:08:29AM -0400, Cyrus Vafadari wrote:\n\n> I am an avid user of this pattern: \"git checkout -b my_branch\n> upstream/3.2.x\", using \"start_point\" to build my backported patch\n> against an old feature version. But in this case, the default tracking\n> is against 3.2.x, rather than my new feature branch. So, then, when I\n> push I specify to update the tracking against the new branch name.\n> There are also various default behaviors for push, which I won't\n> enumerate here, but in the end I need to specify tracking.\n> \n> I'm wondering if there is some usage/pattern I'm missing?\n\nI think it all depends on your workflows and how you use the upstream\ninformation. For instance, I start most of my branches off of the tip of\nthe remote master, similar to you:\n\n  git checkout -b my-topic origin/master\n\nI want to keep that as the upstream for various commands. E.g.,\n\"git-rebase -i\" will use the fork point of the branch by default,\nwithout even having to say \"@{upstream}\".\n\nWhen I push, it goes to a remote branch with a matching name (because I\nhave push.default set to \"current\"). If I want to look at the\nremote-repo version (say, to compare what's happened since I last\npushed), I use the \"@{push}\" shortcut to refer to it (rather than\n\"@{upstream}\"). So for example I often do:\n\n  git range-diff @{push}...HEAD\n\nto see what hasn't yet been pushed (range-diff rather than a regular\n\"log\" because I'm usually rewriting commits via rebase).\n\nNow that's just what _I_ do. There's nothing wrong with setting the\nupstream to the push destination if your workflows prefer that (e.g.,\nbecause you are collaborating with somebody else on the branch and want\nto be able to pull or rebase just the parts that haven't been pushed).\nAnd that's why we have \"push -u\".\n\nBut no, I don't think there's a way to set the upstream to that push\ndestination at the time you run \"git checkout\". I don't think it would\nbe an unreasonable config option to have. Once upon a time it was very\ntricky to say \"the thing that I would push to by default\", because those\nrules were all just encoded inside of git-push. But these days you\nshould be able to reuse the logic that powers @{push}.\n\n-Peff\n"}]}