git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
May 1, 2025, 21:38 UTC
Message-ID
<xmqqo6wcvwo3.fsf@gitster.g>
In-Reply-To
<CALnO6CBR2J8YdGgVLHxxpciAHBe5WjwAb3dRr=aUKU8fzRvzYQ@mail.gmail.com>
"D. Ben Knoble" <ben.knoble@gmail.com> writes:
Show 18 quoted lines
> On Mon, Apr 28, 2025 at 4:12 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> 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.

Show 14 quoted lines
>>  - 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).

Previous: D. Ben Knoble
Message 3 of 3 in “response to "git branch -f foo origin/foo"”
  1. Junio C HamanoApr 28, 2025
  2. D. Ben KnobleMay 1, 2025
  3. Junio C HamanoMay 1, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.