Re: response to "git branch -f foo origin/foo"

"D. Ben Knoble" [off-list ref] writes:

On Mon, Apr 28, 2025 at 4:12 PM Junio C Hamano [off-list ref] wrote:

quoted

When 'X' is a new branch I am creating to automatically (as the
default for branch.autoSetupMerge is true these days) track the
corresponding branch at the upstream, this output ...

    $ git branch [-f] X origin/X
    branch 'X' set up to track 'origin/X'.

... from the command, with or without -f, makes perfect sense.

It also makes sense if we reset the tip of 'X' to a slightly older
commit on the branch, i.e. after doing the above, running

    $ git branch -f X origin/X~4

But why not use `git reset --hard origin/X~4` here? (Answering myself:
presumably because this version works whatever the current branch is.)

Exactly.  After you work on another branch (perhaps your primary
branch) to incorporate the work that was done near the tip of
origin/X, you may want to reset X to lose those now-redundant
commits, but you do not want to switch to X just for that.  After
all, you are "done" with X at that point and want to continue
working on your current branch.

quoted

 - We should give another message when "git branch -f X" resets the
   commit an existing branch X points at.  Unlike "what was X
   tracking?" that is forever lost (hence the previous suggestion),
   what X used to point at can be found out as X@{1}, so it is not
   necessary to give the exact commit, but the fact that the branch
   existed already may be significant (especially if you habitually
   use "branch -f X" whether X exists or not).  Taking inspirations
   from "git checkout -B X origin/X" that says "Switched to and
   reset branch 'X'", perhaps "Reset branch 'X'" may be a good place
   to stop.

Didn't I see you recently suggest someone drop the habit of
unnecessary -r in rm? [1] :) This seems similar to me: don't use
unnecessary -f as a habit.

Even if you do not have that habit, think in what situation you
would use "branch -f X".  You do so when you think you _know_ X
exists already, i.e. you know you are resetting an existing branch,
and not creating a new branch.

But it is possible that the one you wanted to overwrite was Y and
not X---it would give you an extra clue to realize you screwed up if
we gave two different messages (or perhaps "-f" that resets stay
silent, but if "-f" created, give a "created" in a message, or
something).