{"thread":{"id":"63366","subject":"response to \"git branch -f foo origin/foo\"","startedAt":"2025-04-28T20:12:00Z","lastAt":"2025-05-01T21:38:39Z","messageCount":3,"participants":["Junio C Hamano","D. Ben Knoble"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"516911","messageId":"xmqq4iy8cagi.fsf@gitster.g","threadId":"63366","inReplyTo":null,"subject":"response to \"git branch -f foo origin/foo\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-04-28T20:11:57Z","receivedAt":"2025-04-28T20:12:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When 'X' is a new branch I am creating to automatically (as the\ndefault for branch.autoSetupMerge is true these days) track the\ncorresponding branch at the upstream, this output ...\n\n    $ git branch [-f] X origin/X\n    branch 'X' set up to track 'origin/X'.\n\n... from the command, with or without -f, makes perfect sense.\n\nIt also makes sense if we reset the tip of 'X' to a slightly older\ncommit on the branch, i.e. after doing the above, running\n\n    $ git branch -f X origin/X~4\n\ndoes not say anything.  The branch is still set up to track\norigin/X after doing the above two operations.\n\nHowever, after doing these, and 'X' is _already_ tracking its\ncorresponding branch at the upstream, resetting the branch with '-f'\nagain will give us the same message as the first one:\n\n    $ git branch -f X origin/X\n    branch 'X' set up to track 'origin/X'.\n\nand I think it is wrong for at least two reasons:\n\n * Does it make sense to say \"set up to track\" in this case?  If X\n   used to be set to track nothing or some other branch, and if we\n   changed the tracking information with the command, the existing\n   message may make sense, but otherwise, I would say the current\n   message is useless, and it is unnecessarily frustrating, because\n   those who see the message may start to wonder what it was set to\n   track before, but at that point, that information is long lost.\n\n * \"git branch -f\" on an existing branch is done to repoint the\n   branch to point at some commit, which may or may not be the same\n   one as before.  If the starting point happens to be a\n   remote-tracking branch (like \"origin/X\"), it also may set up a\n   tracking information as well, and as the first point argued, it\n   may make sense to report the tracking information _if_ it\n   changed.  But pointing the branch tip at a different commit is a\n   change that is also, if not more, report-worthy event.\n\nSuggesitons.\n\n - We should change the condition under which the \"branch X set up\n   to track origin/X\" message is given.  We should limit it only to\n   the case where X did *NOT* track origin/X, and we made X to track\n   origin/X in this invocation of the command.\n\n - We may want to extend the \"branch X set up to track origin/X\"\n   message so that the message mentions what X used to track, or the\n   fact that X tracked nothing.\n\n - We should give another message when \"git branch -f X\" resets the\n   commit an existing branch X points at.  Unlike \"what was X\n   tracking?\" that is forever lost (hence the previous suggestion),\n   what X used to point at can be found out as X@{1}, so it is not\n   necessary to give the exact commit, but the fact that the branch\n   existed already may be significant (especially if you habitually\n   use \"branch -f X\" whether X exists or not).  Taking inspirations\n   from \"git checkout -B X origin/X\" that says \"Switched to and\n   reset branch 'X'\", perhaps \"Reset branch 'X'\" may be a good place\n   to stop.\n\nComments?  Takers?\n"},{"id":"517058","messageId":"CALnO6CBR2J8YdGgVLHxxpciAHBe5WjwAb3dRr=aUKU8fzRvzYQ@mail.gmail.com","threadId":"63366","inReplyTo":"xmqq4iy8cagi.fsf@gitster.g","subject":"Re: response to \"git branch -f foo origin/foo\"","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-05-01T18:25:02Z","receivedAt":"2025-05-01T18:25:15Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Mon, Apr 28, 2025 at 4:12 PM Junio C Hamano <gitster@pobox.com> wrote:\n>\n> When 'X' is a new branch I am creating to automatically (as the\n> default for branch.autoSetupMerge is true these days) track the\n> corresponding branch at the upstream, this output ...\n>\n>     $ git branch [-f] X origin/X\n>     branch 'X' set up to track 'origin/X'.\n>\n> ... from the command, with or without -f, makes perfect sense.\n>\n> It also makes sense if we reset the tip of 'X' to a slightly older\n> commit on the branch, i.e. after doing the above, running\n>\n>     $ git branch -f X origin/X~4\n\nBut why not use `git reset --hard origin/X~4` here? (Answering myself:\npresumably because this version works whatever the current branch is.)\n\n>\n> does not say anything.  The branch is still set up to track\n> origin/X after doing the above two operations.\n>\n> However, after doing these, and 'X' is _already_ tracking its\n> corresponding branch at the upstream, resetting the branch with '-f'\n> again will give us the same message as the first one:\n>\n>     $ git branch -f X origin/X\n>     branch 'X' set up to track 'origin/X'.\n>\n> and I think it is wrong for at least two reasons:\n>\n>  * Does it make sense to say \"set up to track\" in this case?  If X\n>    used to be set to track nothing or some other branch, and if we\n>    changed the tracking information with the command, the existing\n>    message may make sense, but otherwise, I would say the current\n>    message is useless, and it is unnecessarily frustrating, because\n>    those who see the message may start to wonder what it was set to\n>    track before, but at that point, that information is long lost.\n\nThe other perspective is that\n- it's nice to know the tracking is setup; if I'm used to seeing that\nmessage and I don't, I might wonder where the tracking has gone?\n- use of -f is enough consent to lose the \"what was there before\"\n\nThough, it might still be nice to do the following [reordered]\n\n>  - We may want to extend the \"branch X set up to track origin/X\"\n>    message so that the message mentions what X used to track, or the\n>    fact that X tracked nothing.\n\nThis might be \"noisy\" for confident users, but seems like a nice QoL\nimprovement to me.\n\n>  - We should give another message when \"git branch -f X\" resets the\n>    commit an existing branch X points at.  Unlike \"what was X\n>    tracking?\" that is forever lost (hence the previous suggestion),\n>    what X used to point at can be found out as X@{1}, so it is not\n>    necessary to give the exact commit, but the fact that the branch\n>    existed already may be significant (especially if you habitually\n>    use \"branch -f X\" whether X exists or not).  Taking inspirations\n>    from \"git checkout -B X origin/X\" that says \"Switched to and\n>    reset branch 'X'\", perhaps \"Reset branch 'X'\" may be a good place\n>    to stop.\n\nDidn't I see you recently suggest someone drop the habit of\nunnecessary -r in rm? [1] :) This seems similar to me: don't use\nunnecessary -f as a habit. I would personally find it noisy, but again\nfor newer users it may be helpful. I can't judge that well (only that\nit would lose some \"silence means success\").\n\n[1]: https://lore.kernel.org/git/xmqqecxk3u5l.fsf@gitster.g/\n\n-- \nD. Ben Knoble\n"},{"id":"517068","messageId":"xmqqo6wcvwo3.fsf@gitster.g","threadId":"63366","inReplyTo":"CALnO6CBR2J8YdGgVLHxxpciAHBe5WjwAb3dRr=aUKU8fzRvzYQ@mail.gmail.com","subject":"Re: response to \"git branch -f foo origin/foo\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-05-01T21:38:36Z","receivedAt":"2025-05-01T21:38:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"D. Ben Knoble\" <ben.knoble@gmail.com> writes:\n\n> On Mon, Apr 28, 2025 at 4:12 PM Junio C Hamano <gitster@pobox.com> wrote:\n>>\n>> When 'X' is a new branch I am creating to automatically (as the\n>> default for branch.autoSetupMerge is true these days) track the\n>> corresponding branch at the upstream, this output ...\n>>\n>>     $ git branch [-f] X origin/X\n>>     branch 'X' set up to track 'origin/X'.\n>>\n>> ... from the command, with or without -f, makes perfect sense.\n>>\n>> It also makes sense if we reset the tip of 'X' to a slightly older\n>> commit on the branch, i.e. after doing the above, running\n>>\n>>     $ git branch -f X origin/X~4\n>\n> But why not use `git reset --hard origin/X~4` here? (Answering myself:\n> presumably because this version works whatever the current branch is.)\n\nExactly.  After you work on another branch (perhaps your primary\nbranch) to incorporate the work that was done near the tip of\norigin/X, you may want to reset X to lose those now-redundant\ncommits, but you do not want to switch to X just for that.  After\nall, you are \"done\" with X at that point and want to continue\nworking on your current branch.\n\n>>  - We should give another message when \"git branch -f X\" resets the\n>>    commit an existing branch X points at.  Unlike \"what was X\n>>    tracking?\" that is forever lost (hence the previous suggestion),\n>>    what X used to point at can be found out as X@{1}, so it is not\n>>    necessary to give the exact commit, but the fact that the branch\n>>    existed already may be significant (especially if you habitually\n>>    use \"branch -f X\" whether X exists or not).  Taking inspirations\n>>    from \"git checkout -B X origin/X\" that says \"Switched to and\n>>    reset branch 'X'\", perhaps \"Reset branch 'X'\" may be a good place\n>>    to stop.\n>\n> Didn't I see you recently suggest someone drop the habit of\n> unnecessary -r in rm? [1] :) This seems similar to me: don't use\n> unnecessary -f as a habit.\n\nEven if you do not have that habit, think in what situation you\nwould use \"branch -f X\".  You do so when you think you _know_ X\nexists already, i.e. you know you are resetting an existing branch,\nand not creating a new branch.\n\nBut it is possible that the one you wanted to overwrite was Y and\nnot X---it would give you an extra clue to realize you screwed up if\nwe gave two different messages (or perhaps \"-f\" that resets stay\nsilent, but if \"-f\" created, give a \"created\" in a message, or\nsomething).\n"}]}