git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: response to "git branch -f foo origin/foo"
Date: Mon, 28 Apr 2025 13:11:57 -0700	[thread overview]
Message-ID: <xmqq4iy8cagi.fsf@gitster.g> (raw)

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

does not say anything.  The branch is still set up to track
origin/X after doing the above two operations.

However, after doing these, and 'X' is _already_ tracking its
corresponding branch at the upstream, resetting the branch with '-f'
again will give us the same message as the first one:

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

and I think it is wrong for at least two reasons:

 * Does it make sense to say "set up to track" in this case?  If X
   used to be set to track nothing or some other branch, and if we
   changed the tracking information with the command, the existing
   message may make sense, but otherwise, I would say the current
   message is useless, and it is unnecessarily frustrating, because
   those who see the message may start to wonder what it was set to
   track before, but at that point, that information is long lost.

 * "git branch -f" on an existing branch is done to repoint the
   branch to point at some commit, which may or may not be the same
   one as before.  If the starting point happens to be a
   remote-tracking branch (like "origin/X"), it also may set up a
   tracking information as well, and as the first point argued, it
   may make sense to report the tracking information _if_ it
   changed.  But pointing the branch tip at a different commit is a
   change that is also, if not more, report-worthy event.

Suggesitons.

 - We should change the condition under which the "branch X set up
   to track origin/X" message is given.  We should limit it only to
   the case where X did *NOT* track origin/X, and we made X to track
   origin/X in this invocation of the command.

 - We may want to extend the "branch X set up to track origin/X"
   message so that the message mentions what X used to track, or the
   fact that X tracked nothing.

 - 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.

Comments?  Takers?

             reply	other threads:[~2025-04-28 20:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-28 20:11 Junio C Hamano [this message]
2025-05-01 18:25 ` response to "git branch -f foo origin/foo" D. Ben Knoble
2025-05-01 21:38   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq4iy8cagi.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).