"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> When a branch tracks a non-default remote branch (e.g.,
> origin/feature), git status now also displays how the branch
> compares to the default branch (origin/main or upstream/main).

"now" meaning what"?

The usual way to compose a log message of this project is to

 - Give an observation on how the current system works in the
   present tense (so no need to say "Currently X is Y", or
   "Previously X was Y" to describe the state before your change;
   just "X is Y" is enough), and discuss what you perceive as a
   problem in it.

 - Propose a solution (optional---often, problem description
   trivially leads to an obvious solution in reader's minds).

 - Give commands to somebody editing the codebase to "make it so",
   instead of saying "This commit does X".

in this order.

So if you are following the convention, "now also displays" ought to
be about what the current code without this patch does, but I am
sensing that it probably is not the case.

Start your explanation by decribing what the users see in "git
status" output without this patch.  Perhaps like

    "git status" on a branch that follows a remote branch compares
    commits on the current branch and the remote-tracking branch it
    builds upon, to show "ahead" (i.e. you have built new history,
    while others are not touching it), "behind" (i.e. you haven't
    added any work since you were in-sync, while others have added
    their work on the branch), "diverged" (i.e. you have commits
    that you haven't pushed out, while others have added commits).

That is the "giving an observation" part.  And then describe why
that comparison with a single remote branch may be insufficient to
learn the current status.  Your reasoning might be something like

    When you fork a branch 'feature' from the 'main' branch of the
    remote, but then create 'feature' branch at the remote and push
    there, while you still occasionally pull from or rebase onto
    their 'main', you'd _also_ want to know how much you have
    diverged from 'main', in addition to how your 'feature' and
    their 'feature' compares.  Currently the comparison with 'main'
    is not given.

That's the "discuss your problem with the status quo" part.

Only after that, propose to show two sets of comparison.

> This helps users understand if their branch has drifted from the
> main development line even when it's in sync with its tracking
> branch.

Describe what does it help to know that after that sentence, like
"... to get the feel of when to start thinking about rebasing", or
something.

> The comparison is shown as a separate line after the tracking
> branch status:
> - "Ahead of 'origin/main' by N commits" when purely ahead
> - "Behind 'origin/main' by N commits" when purely behind
> - "Diverged from 'origin/main' by N commits" when diverged

In other words, exactly the same way as what we show with the
tracking branch?

The triangular workflow involves two remote things.  One is where
you pull from to catch up.  After building on top, you push to
somewhere else to publish your work.  This may be a different branch
in the same repository you pull from, or a branch in a completely
different repository.  What you pushed out may be processed by
others and may come back in the branch you pull from eventually to
complete the triangle.

In such a triangular workflow, comparison with these two remote
things may be needed. One with the branch you forked your work from
to know how much work _other_ people added to the branch to learn
when to start thinking about catching up, and with the branch you
are pushing your work to to know how much work you are holding
locally without pushing out.

I am not sure what you mean by the word "default" here, though.

You seem to be using the "what would a new user get when they clone
the remote (by virtue of their HEAD pointing at that branch)", but
I am not sure if that is a good way to determine the other remote
thing to compare with.

Even if one remote branch you pull from (but not push to) has a name
that is not one of those usual ones like 'main', 'master', 'trunk',
'default', you would want to compare with it in addition to where
you are pushing to.  So branch.<name>.merge + branch.<name>.remote
that defines where you pull from is one thing to compare with.  To
learn the other, the destination of a push of this branch, would
involve poking at remote.pushdefault, branch.<name>.pushRemote,
branch.<name>.remote to find out which remote repository it goes,
and then remote.<remote>.push to find out where this branch goes,
but the helper functions to learn all that are already available.

So, I think the topic addresses a good problem, its presentation
needs a bit more work, and its design (not the implementation) of
how to figure out the other thing to compare I am not sure about.

Thanks.

> In other words, exactly the same way as what we show with the
> tracking branch?
> 
> The triangular workflow involves two remote things.  One is where
> you pull from to catch up.  After building on top, you push to
> somewhere else to publish your work.  This may be a different branch
> in the same repository you pull from, or a branch in a completely
> different repository.  What you pushed out may be processed by
> others and may come back in the branch you pull from eventually to
> complete the triangle.
> 
> In such a triangular workflow, comparison with these two remote
> things may be needed. One with the branch you forked your work from
> to know how much work _other_ people added to the branch to learn
> when to start thinking about catching up, and with the branch you
> are pushing your work to to know how much work you are holding
> locally without pushing out.

Yes, it's the same as when tracking master/main, but with far less complexity for the end-user. For many years I have had the habit of running these on my feature branches:

	git checkout -b feature_branch
	git branch --set-upstream-to origin/$(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')

	# To merge in other's code early
	git pull --rebase origin $(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')

	# To push to correct branch, because I'm tracking default instead "feature_branch"
	git push origin $(git rev-parse --abbrev-ref HEAD)

I have found this very hard to explain the benefits of this to other developers. Git is already scary to many, they are afraid of losing work, so they would rather not mess with the tracking branches and break the regular "git push" functionality.

For me, I feel blind of I can't see how my branch compares the master/main at all times.

> I am not sure what you mean by the word "default" here, though.
> 
> You seem to be using the "what would a new user get when they clone
> the remote (by virtue of their HEAD pointing at that branch)", but
> I am not sure if that is a good way to determine the other remote
> thing to compare with.
>
> Even if one remote branch you pull from (but not push to) has a name
> that is not one of those usual ones like 'main', 'master', 'trunk',
> 'default'

Agreed, this should be as agnostic as possible. "Default" might be me using GitHub terminology. However, it seems that 'git symbolic-ref refs/remotes/upstream/HEAD' always produces the desires result, so for the sake of discussion we can call it "upstream/HEAD" instead of "default".

Harald

(Adding another comment to my own thread to reply to Junio C Hamano)

> branch.<name>.merge + branch.<name>.remote
> that defines where you pull from is one thing to compare with.  To
> learn the other, the destination of a push of this branch, would
> involve poking at remote.pushdefault, branch.<name>.pushRemote,
> branch.<name>.remote to find out which remote repository it goes,
> and then remote.<remote>.push to find out where this branch goes,
> but the helper functions to learn all that are already available.

When a new branch is created it has no push settings:

	git checkout -b ahead_of_main_status__tmp2

	git push
	fatal: The current branch ahead_of_main_status__tmp2 has no upstream branch.
	To push the current branch and set the remote as upstream, use

    	git push --set-upstream origin ahead_of_main_status__tmp2

	To have this happen automatically for branches without a tracking
	upstream, see 'push.autoSetupRemote' in 'git help config'.

Once the users runs that suggested command

	git push --set-upstream origin ahead_of_main_status__tmp2

then the 'branch.<name>.merge' and 'branch.<name>.remote' no longer hold the reference to "upstream/HEAD".

For sure, it would be great to re-use previous logic for this, but can it really be done without new logic?

Harald

On Tue, Dec 23, 2025 at 3:36 AM Harald Nordgren
<haraldnordgren@gmail.com> wrote:
> Once the users runs that suggested command
>
>         git push --set-upstream origin ahead_of_main_status__tmp2
>
> then the 'branch.<name>.merge' and 'branch.<name>.remote' no longer hold the reference to "upstream/HEAD".

Right.

And, as Junio noted, to:

>> learn the other, the destination of a push of this branch, would
>> involve poking at remote.pushdefault, branch.<name>.pushRemote,
>> branch.<name>.remote to find out which remote repository it goes,
>> and then remote.<remote>.push to find out where this branch goes,

That is, there are some separate configuration items that can change
where `git push` goes.

Using `git push --set-upstream` sets ones that affect `git pull`, `git status`,
and `git push`, but it's possible to set ones that affect only `git push`.

That still leaves `git status` with the problem you (Harald) have observed,
so perhaps the path forward is to have `git status` check things like
branch.<name>.pushRemote to see if they exist and differ from
branch.<name>.remote.

Chris

Harald Nordgren <haraldnordgren@gmail.com> writes:

>> You seem to be using the "what would a new user get when they clone
>> the remote (by virtue of their HEAD pointing at that branch)", but
>> I am not sure if that is a good way to determine the other remote
>> thing to compare with.
>>
>> Even if one remote branch you pull from (but not push to) has a name
>> that is not one of those usual ones like 'main', 'master', 'trunk',
>> 'default'
>
> Agreed, this should be as agnostic as possible. "Default" might be
> me using GitHub terminology. However, it seems that 'git
> symbolic-ref refs/remotes/upstream/HEAD' always produces the
> desires result, so for the sake of discussion we can call it
> "upstream/HEAD" instead of "default".

I didn't exactly question the terminology, but was wondering more
about the wisdom of using remotes/*/HEAD.

If a project uses the same remote repository to maintain its
maintenance and development tracks, their HEAD might point at the
'main' (used for development), but some of your branches you used to
work on fixes that can later be merged to the maintenance track, it
is likely that you'll fork from their 'maint', and while you keep
polishing your fixes, you may push your 'fix' branch to their 'fix'
branch.  Comparing your 'fix' with their 'fix' is what we already
do, and it gives two thirds of what you need, but the missing
comparison is with their 'maint', not with their HEAD that points at
their 'main'.

Thanks.

> If a project uses the same remote repository to maintain its
> maintenance and development tracks, their HEAD might point at the
> 'main' (used for development), but some of your branches you used to
> work on fixes that can later be merged to the maintenance track, it
> is likely that you'll fork from their 'maint', and while you keep
> polishing your fixes, you may push your 'fix' branch to their 'fix'
> branch.  Comparing your 'fix' with their 'fix' is what we already
> do, and it gives two thirds of what you need, but the missing
> comparison is with their 'maint', not with their HEAD that points at
> their 'main'.

That's a fair point. I am used to trunk-based development, but I recognize
that there are other paradigms out there.

One possibly solution could be to make this adjustable in repo-wide config
(maybe 'repo.settings.defaultBranch=maint') and when unset it compares to
'refs/remotes/upstream/HEAD'?

> That still leaves `git status` with the problem you (Harald) have observed,
> so perhaps the path forward is to have `git status` check things like
> branch.<name>.pushRemote to see if they exist and differ from
> branch.<name>.remote.

I played around with pushRemote and I'm not getting it to do something
that's useful for me here. Granted I'm not an expert there so happy to take
some hints on how to use it more specifically.

I checked some of my other projects and it seems pushRemote doesn't get
set, even when working with one fork and one upstream repo:

	$ git remote -v
	HaraldNordgren	git@github.com:HaraldNordgren/brew.git (fetch)
	HaraldNordgren	git@github.com:HaraldNordgren/brew.git (push)
	origin	git@github.com:Homebrew/brew.git (fetch)
	origin	git@github.com:Homebrew/brew.git (push)

Harald

On Tue, Dec 23, 2025 at 6:18 AM Harald Nordgren
<haraldnordgren@gmail.com> wrote:
> I played around with pushRemote and I'm not getting it to do something
> that's useful for me here. Granted I'm not an expert there so happy to take
> some hints on how to use it more specifically.

I've never actually used it myself. You do have to set it manually
(with `git config` for instance).

I've never been completely convinced that Git's triangular workflow
setups are The Right Way, or even a Good Way. I've always just
done everything manually. But they're documented, so they ought
to work.

Chris

> The default branch is determined dynamically by checking:
> 1. refs/remotes/upstream/HEAD (if upstream remote exists)
> 2. refs/remotes/origin/HEAD (fallback)

I feel like this is making a lot of assumptions regarding remotes.
"origin" and "upstream" are not inherently special names for remotes.
I personally have different Git repositories where they could mean
slightly different things, and I don't use the "upstream" wording
myself (I sometimes use "official" for the upstream branch, and/or
"ychin" for my own fork's remote). Feels like we should not be
imposing such a hard-coded value when nothing else in Git enforces it.

Also, when there are multiple remotes, it's not always clear which one
the user actually cares about. It's not always clear if they care
about the upstream or the downstream remote, of a third one that
actually matters more.

This would also work poorly with detached branches (e.g. the popular
'gh-pages' branches in a lot of repositories), or permanently foked
branches like fixed versions (e.g. v2.x legacy branch when the
software main branch moved to v3.0). Seems like for this to work well
it would need to be configurable per branch. Even on a repository
level there would likely be lots of edge cases with each branch having
its unique circumstances.

These are very fair points, maybe a reason not to have this feature on by default then.

For me, I work against clear origin/master, origin/master, origin/develop branches at my dayjob, and when I do open-source there is a default branch to work against. The GitHub 'gh' tool defaults to upstream and origin repos, which is why I chose those. But I agree it might not be right for everyone.

Maybe what I wrote in a previous message about making this configurable via 'repo.settings.defaultBranch' (maybe call it 'repo.settings.statusGoalBranch') would be useful, but having it off by default instead of on by default as I originally suggested.

I feel strongly that it should be able to be set be repo-specific (and globally). Having it only per branch defeats a big part of it. Should be straightforward git config to have a repo-wide rule but still allow disabling it for e.g. 'gh-pages', I hope?


Harald

By the way, I'm using my own version of git while working on this, and I'm loving it 😅

	$ /Users/Harald/git-repos/github.com/git/git/git status
	On branch ahead_of_main_status
	Your branch and 'origin/ahead_of_main_status' have diverged,
	and have 1 and 1 different commits each, respectively.
	  (use "git pull" if you want to integrate the remote branch with yours)

	Ahead of 'upstream/master' by 2 commits.

	nothing to commit, working tree clean