threads / patch / 66593

patchstatus: compare against both upstream and push branch by default

Subject: [PATCH] status: compare against both upstream and push branch by default

## tl;dr

The proposal would change default git status output for users whose push branch differs from their upstream, and Junio C Hamano says the case for it has not yet been made. Read the story.

replies: 15people: 5as markdown or json

Harald Nordgren via GitGitGadget· Oct 19, 2026, 19:23 UTC · lore
From: Harald Nordgren <haraldnordgren@gmail.com>

In a triangular workflow, where a branch is pulled from one place and pushed to another, "git status" only compares the branch to its upstream. It says nothing about the branch it is pushed to unless status.compareBranches is configured.

Show both comparisons by default. When the two resolve to the same branch, which is the common case, only one comparison is shown, so the output for most users does not change. Setting status.compareBranches to "@{upstream}" gives the previous output.

Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
    status: compare against both upstream and push branch by default
    
    Make @{upstream} @{push} the default for status.compareBranches. When
    both resolve to the same branch only one comparison is shown, so most
    users see no change.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2458%2FHaraldNordgren%2Fstatus-compare-branches-default-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2458/HaraldNordgren/status-compare-branches-default-v1
Pull-Request: https://github.com/git/git/pull/2458
 Documentation/config/status.adoc | 11 ++++++-----
 remote.c                         |  1 +
 t/t5505-remote.sh                |  1 -
 t/t6040-tracking-info.sh         | 30 +++++++++++++++---------------
 4 files changed, 22 insertions(+), 21 deletions(-)
Show changes to 4 files +22 −21

Documentation/config/status.adoc, remote.c, t/t5505-remote.sh, t/t6040-tracking-info.sh

diff --git a/Documentation/config/status.adoc b/Documentation/config/status.adoc
index b5dd85b761..1d847d3a8a 100644
--- a/Documentation/config/status.adoc
+++ b/Documentation/config/status.adoc
@@ -23,8 +23,9 @@ status.compareBranches::
 	are supported. They are interpreted as `branch@{upstream}` and
 	`branch@{push}` for the current branch.
 +
-If not set, the default behavior is equivalent to `@{upstream}`, which
-compares against the configured upstream tracking branch.
+If not set, the default behavior is equivalent to `@{upstream} @{push}`,
+which compares against both the configured upstream and push tracking
+branches.
 +
 The entries are shown in the order they appear in the configuration.
 Duplicate entries that resolve to the same ref are suppressed after
@@ -36,11 +37,11 @@ Example:
 +
 ----
 [status]
-	compareBranches = @{upstream} @{push}
+	compareBranches = @{upstream}
 ----
 +
-This would show comparisons against both the configured upstream and push
-tracking branches for the current branch.
+This would only show the comparison against the configured upstream
+tracking branch for the current branch.
 
 status.displayCommentPrefix::
 	If set to true, linkgit:git-status[1] will insert a comment
diff --git a/remote.c b/remote.c
index 71170f36a9..6fdb4b84da 100644
--- a/remote.c
+++ b/remote.c
@@ -2465,6 +2465,7 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb,
 		string_list_remove_empty_items(&branches, 0);
 	} else {
 		string_list_append(&branches, "@{upstream}");
+		string_list_append(&branches, "@{push}");
 	}
 
 	upstream_ref = branch_get_upstream(branch, NULL);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 5fbfcb0848..f77753605f 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -34,7 +34,6 @@ setup_url_pushremote () {
 		git checkout -b topic --track origin/main &&
 		git commit --allow-empty -m topic-change &&
 		git config push.default current &&
-		git config status.compareBranches "@{upstream} @{push}" &&
 		git config branch.topic.pushRemote "$fork_url" &&
 		git push
 	)
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index e95d420972..e10cde090d 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -331,19 +331,6 @@ test_expect_success 'status.compareBranches deduplicates when upstream and push
 	test_cmp expect actual
 '
 
-test_expect_success 'status.compareBranches with only upstream shows only upstream' '
-	test_config -C test status.compareBranches "@{upstream}" &&
-	git -C test checkout main &&
-	git -C test status >actual &&
-	cat >expect <<-EOF &&
-	On branch main
-	Your branch is up to date with ${SQ}origin/main${SQ}.
-
-	nothing to commit, working tree clean
-	EOF
-	test_cmp expect actual
-'
-
 test_expect_success 'status.compareBranches with only push shows only push' '
 	test_config -C test push.default current &&
 	test_config -C test status.compareBranches "@{push}" &&
@@ -361,9 +348,8 @@ test_expect_success 'status.compareBranches with only push shows only push' '
 	test_cmp expect actual
 '
 
-test_expect_success 'status.compareBranches shows ahead of both upstream and push branch' '
+test_expect_success 'status shows ahead of both upstream and push branch by default' '
 	test_config -C test push.default current &&
-	test_config -C test status.compareBranches "@{upstream} @{push}" &&
 	git -C test checkout -b feature3 origin/main &&
 	git -C test push origin HEAD &&
 	(cd test && advance work) &&
@@ -380,6 +366,20 @@ test_expect_success 'status.compareBranches shows ahead of both upstream and pus
 	test_cmp expect actual
 '
 
+test_expect_success 'status.compareBranches with only upstream shows only upstream' '
+	test_config -C test push.default current &&
+	test_config -C test status.compareBranches "@{upstream}" &&
+	git -C test checkout feature3 &&
+	git -C test status >actual &&
+	cat >expect <<-EOF &&
+	On branch feature3
+	Your branch is ahead of ${SQ}origin/main${SQ} by 1 commit.
+
+	nothing to commit, working tree clean
+	EOF
+	test_cmp expect actual
+'
+
 test_expect_success 'checkout with status.compareBranches shows both branches' '
 	test_config -C test push.default current &&
 	test_config -C test status.compareBranches "@{upstream} @{push}" &&

base-commit: c51408889c3b372814bc20b9431c3b74d0d268eb
-- 
gitgitgadget
Junio C Hamano· Oct 19, 2026, 22:54 UTC · re: Harald Nordgren via GitGitGadget · lore

Re: [PATCH] status: compare against both upstream and push branch by default

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 6 quoted lines
> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> In a triangular workflow, where a branch is pulled from one place and
> pushed to another, "git status" only compares the branch to its
> upstream. It says nothing about the branch it is pushed to unless
> status.compareBranches is configured.

I would have expected such an explanation to be on a commit that allowed this default change to be such a small code change (i.e., the commit that added support for status.compareBranches). In other words, shouldn't the first paragraph be more like this:

    Commit XXXXX added status.compareBranches so that "git status"
    can show comparison of the current branch with its upstream in
    addition to where the branch is pushed to, which is great to
    support the triangular workflow.  It however did not make it the
    default to show both.

It would highlight that the primary task this commit wants to achieve is to change the default, which is explained next.

> Show both comparisons by default. When the two resolve to the same
> branch, which is the common case, only one comparison is shown, so the
> output for most users does not change. Setting status.compareBranches
> to "@{upstream}" gives the previous output.

Most users not seeing any change is not a good excuse to make a default change. Thinking through different use cases and see if there are cases where negative impact is made relative to the current one is how we should evaluate.

In this case, especially given that this is "git status" output that is meant to shown to interactive end-users, I do not think of a reason why those who use triangular workflows would not want to see both by default.

Show 12 quoted lines
> -test_expect_success 'status.compareBranches with only upstream shows only upstream' '
> -	test_config -C test status.compareBranches "@{upstream}" &&
> -	git -C test checkout main &&
> -	git -C test status >actual &&
> -	cat >expect <<-EOF &&
> -	On branch main
> -	Your branch is up to date with ${SQ}origin/main${SQ}.
> -
> -	nothing to commit, working tree clean
> -	EOF
> -	test_cmp expect actual
> -'
What's this deletion about?  Is this duplicated or something?
Show 11 quoted lines
> @@ -361,9 +348,8 @@ test_expect_success 'status.compareBranches with only push shows only push' '
>  	test_cmp expect actual
>  '
>  
> -test_expect_success 'status.compareBranches shows ahead of both upstream and push branch' '
> +test_expect_success 'status shows ahead of both upstream and push branch by default' '
>  	test_config -C test push.default current &&
> -	test_config -C test status.compareBranches "@{upstream} @{push}" &&
>  	git -C test checkout -b feature3 origin/main &&
>  	git -C test push origin HEAD &&
>  	(cd test && advance work) &&

Even if the default changed, shouldn't we make sure that the configuration also work as expected?

In other words, the changes to the tests I would expect from a change like this is (1) to update the tests that have been relying on the old default to gain test_config to explicitly set the old default, and (2) new test that demonstrates the new behaviour without configuration. That assumes that the test coverage before the patch is adequate, which may not have been the case for this test and further changes may be warranted. It is not quite clear to me, but the addition we see below is such a case our existing test failed to cover?

One large argument the proposed commit log message hangs its decision to change the default on is that we won't see extra output when @{upstream} and @{push} happen to point at the same place, so naturally I'd expect to have two tests that show the two cases (i.e., one with triangular, the other just pulling from where you push to). With this test update, do we have adequate test coverage for these cases? If so, that is something we should explain in the proposed commit log message, too.

Thanks.
Show 13 quoted lines
> +test_expect_success 'status.compareBranches with only upstream shows only upstream' '
> +	test_config -C test push.default current &&
> +	test_config -C test status.compareBranches "@{upstream}" &&
> +	git -C test checkout feature3 &&
> +	git -C test status >actual &&
> +	cat >expect <<-EOF &&
> +	On branch feature3
> +	Your branch is ahead of ${SQ}origin/main${SQ} by 1 commit.
> +
> +	nothing to commit, working tree clean
> +	EOF
> +	test_cmp expect actual
> +'
Harald Nordgren· Oct 20, 2026, 09:16 UTC · re: Junio C Hamano · lore

Re: [PATCH] status: compare against both upstream and push branch by default

Show 18 quoted lines
> > In a triangular workflow, where a branch is pulled from one place and
> > pushed to another, "git status" only compares the branch to its
> > upstream. It says nothing about the branch it is pushed to unless
> > status.compareBranches is configured.
>
> I would have expected such an explanation to be on a commit that
> allowed this default change to be such a small code change (i.e.,
> the commit that added support for status.compareBranches).  In other
> words, shouldn't the first paragraph be more like this:
>
>     Commit XXXXX added status.compareBranches so that "git status"
>     can show comparison of the current branch with its upstream in
>     addition to where the branch is pushed to, which is great to
>     support the triangular workflow.  It however did not make it the
>     default to show both.
>
> It would highlight that the primary task this commit wants to
> achieve is to change the default, which is explained next.
Fair enough, thanks!
Show 14 quoted lines
> > -test_expect_success 'status.compareBranches with only upstream shows only upstream' '
> > -     test_config -C test status.compareBranches "@{upstream}" &&
> > -     git -C test checkout main &&
> > -     git -C test status >actual &&
> > -     cat >expect <<-EOF &&
> > -     On branch main
> > -     Your branch is up to date with ${SQ}origin/main${SQ}.
> > -
> > -     nothing to commit, working tree clean
> > -     EOF
> > -     test_cmp expect actual
> > -'
>
> What's this deletion about?  Is this duplicated or something?
I adapted it into another test further down.
But I'll bring things back closer to the old coverage and add more instead.
Show 33 quoted lines
> > @@ -361,9 +348,8 @@ test_expect_success 'status.compareBranches with only push shows only push' '
> >       test_cmp expect actual
> >  '
> >
> > -test_expect_success 'status.compareBranches shows ahead of both upstream and push branch' '
> > +test_expect_success 'status shows ahead of both upstream and push branch by default' '
> >       test_config -C test push.default current &&
> > -     test_config -C test status.compareBranches "@{upstream} @{push}" &&
> >       git -C test checkout -b feature3 origin/main &&
> >       git -C test push origin HEAD &&
> >       (cd test && advance work) &&
>
> Even if the default changed, shouldn't we make sure that the
> configuration also work as expected?
>
> In other words, the changes to the tests I would expect from a
> change like this is (1) to update the tests that have been relying
> on the old default to gain test_config to explicitly set the old
> default, and (2) new test that demonstrates the new behaviour
> without configuration.  That assumes that the test coverage before
> the patch is adequate, which may not have been the case for this
> test and further changes may be warranted.  It is not quite clear
> to me, but the addition we see below is such a case our existing
> test failed to cover?
>
> One large argument the proposed commit log message hangs its
> decision to change the default on is that we won't see extra output
> when @{upstream} and @{push} happen to point at the same place, so
> naturally I'd expect to have two tests that show the two cases
> (i.e., one with triangular, the other just pulling from where you
> push to).  With this test update, do we have adequate test coverage
> for these cases?  If so, that is something we should explain in the
> proposed commit log message, too.
Make sense, yes.
Harald
Phillip Wood· Oct 20, 2026, 09:33 UTC · re: Harald Nordgren via GitGitGadget · lore

Re: [PATCH] status: compare against both upstream and push branch by default

Hi Harald
On 19/10/2026 20:23, Harald Nordgren via GitGitGadget wrote:
Show 15 quoted lines
> From: Harald Nordgren <haraldnordgren@gmail.com>
> > In a triangular workflow, where a branch is pulled from one place and
> pushed to another, "git status" only compares the branch to its
> upstream. It says nothing about the branch it is pushed to unless
> status.compareBranches is configured.
> > Show both comparisons by default. When the two resolve to the same
> branch, which is the common case, only one comparison is shown, so the
> output for most users does not change. Setting status.compareBranches
> to "@{upstream}" gives the previous output.
> > Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
> ---
>      status: compare against both upstream and push branch by default
>      >      Make @{upstream} @{push} the default for status.compareBranches. When
>      both resolve to the same branch only one comparison is shown, so most
>      users see no change.
If you want to change the default value of a config variable it is helpful to explain why the current default was chosen as well as why you think the new default is better. In this case wasn't there some discussion about the default value when the variable was introduced? Providing that context would make it much easier for people to judge if this change is a good idea.
Thanks
Phillip
Show 115 quoted lines
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2458%2FHaraldNordgren%2Fstatus-compare-branches-default-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2458/HaraldNordgren/status-compare-branches-default-v1
> Pull-Request: https://github.com/git/git/pull/2458
> >   Documentation/config/status.adoc | 11 ++++++-----
>   remote.c                         |  1 +
>   t/t5505-remote.sh                |  1 -
>   t/t6040-tracking-info.sh         | 30 +++++++++++++++---------------
>   4 files changed, 22 insertions(+), 21 deletions(-)
> > diff --git a/Documentation/config/status.adoc b/Documentation/config/status.adoc
> index b5dd85b761..1d847d3a8a 100644
> --- a/Documentation/config/status.adoc
> +++ b/Documentation/config/status.adoc
> @@ -23,8 +23,9 @@ status.compareBranches::
>   	are supported. They are interpreted as `branch@{upstream}` and
>   	`branch@{push}` for the current branch.
>   +
> -If not set, the default behavior is equivalent to `@{upstream}`, which
> -compares against the configured upstream tracking branch.
> +If not set, the default behavior is equivalent to `@{upstream} @{push}`,
> +which compares against both the configured upstream and push tracking
> +branches.
>   +
>   The entries are shown in the order they appear in the configuration.
>   Duplicate entries that resolve to the same ref are suppressed after
> @@ -36,11 +37,11 @@ Example:
>   +
>   ----
>   [status]
> -	compareBranches = @{upstream} @{push}
> +	compareBranches = @{upstream}
>   ----
>   +
> -This would show comparisons against both the configured upstream and push
> -tracking branches for the current branch.
> +This would only show the comparison against the configured upstream
> +tracking branch for the current branch.
>   >   status.displayCommentPrefix::
>   	If set to true, linkgit:git-status[1] will insert a comment
> diff --git a/remote.c b/remote.c
> index 71170f36a9..6fdb4b84da 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -2465,6 +2465,7 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb,
>   		string_list_remove_empty_items(&branches, 0);
>   	} else {
>   		string_list_append(&branches, "@{upstream}");
> +		string_list_append(&branches, "@{push}");
>   	}
>   >   	upstream_ref = branch_get_upstream(branch, NULL);
> diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
> index 5fbfcb0848..f77753605f 100755
> --- a/t/t5505-remote.sh
> +++ b/t/t5505-remote.sh
> @@ -34,7 +34,6 @@ setup_url_pushremote () {
>   		git checkout -b topic --track origin/main &&
>   		git commit --allow-empty -m topic-change &&
>   		git config push.default current &&
> -		git config status.compareBranches "@{upstream} @{push}" &&
>   		git config branch.topic.pushRemote "$fork_url" &&
>   		git push
>   	)
> diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
> index e95d420972..e10cde090d 100755
> --- a/t/t6040-tracking-info.sh
> +++ b/t/t6040-tracking-info.sh
> @@ -331,19 +331,6 @@ test_expect_success 'status.compareBranches deduplicates when upstream and push
>   	test_cmp expect actual
>   '
>   > -test_expect_success 'status.compareBranches with only upstream shows only upstream' '
> -	test_config -C test status.compareBranches "@{upstream}" &&
> -	git -C test checkout main &&
> -	git -C test status >actual &&
> -	cat >expect <<-EOF &&
> -	On branch main
> -	Your branch is up to date with ${SQ}origin/main${SQ}.
> -
> -	nothing to commit, working tree clean
> -	EOF
> -	test_cmp expect actual
> -'
> -
>   test_expect_success 'status.compareBranches with only push shows only push' '
>   	test_config -C test push.default current &&
>   	test_config -C test status.compareBranches "@{push}" &&
> @@ -361,9 +348,8 @@ test_expect_success 'status.compareBranches with only push shows only push' '
>   	test_cmp expect actual
>   '
>   > -test_expect_success 'status.compareBranches shows ahead of both upstream and push branch' '
> +test_expect_success 'status shows ahead of both upstream and push branch by default' '
>   	test_config -C test push.default current &&
> -	test_config -C test status.compareBranches "@{upstream} @{push}" &&
>   	git -C test checkout -b feature3 origin/main &&
>   	git -C test push origin HEAD &&
>   	(cd test && advance work) &&
> @@ -380,6 +366,20 @@ test_expect_success 'status.compareBranches shows ahead of both upstream and pus
>   	test_cmp expect actual
>   '
>   > +test_expect_success 'status.compareBranches with only upstream shows only upstream' '
> +	test_config -C test push.default current &&
> +	test_config -C test status.compareBranches "@{upstream}" &&
> +	git -C test checkout feature3 &&
> +	git -C test status >actual &&
> +	cat >expect <<-EOF &&
> +	On branch feature3
> +	Your branch is ahead of ${SQ}origin/main${SQ} by 1 commit.
> +
> +	nothing to commit, working tree clean
> +	EOF
> +	test_cmp expect actual
> +'
> +
>   test_expect_success 'checkout with status.compareBranches shows both branches' '
>   	test_config -C test push.default current &&
>   	test_config -C test status.compareBranches "@{upstream} @{push}" &&
> > base-commit: c51408889c3b372814bc20b9431c3b74d0d268eb
Harald Nordgren· Oct 20, 2026, 10:19 UTC · re: Phillip Wood · lore

Re: [PATCH] status: compare against both upstream and push branch by default

Show 6 quoted lines
> If you want to change the default value of a config variable it is
> helpful to explain why the current default was chosen as well as why you
> think the new default is better. In this case wasn't there some
> discussion about the default value when the variable was introduced?
> Providing that context would make it much easier for people to judge if
> this change is a good idea.
That's fair.
Show 123 quoted lines
> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2458%2FHaraldNordgren%2Fstatus-compare-branches-default-v1
> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2458/HaraldNordgren/status-compare-branches-default-v1
> > Pull-Request: https://github.com/git/git/pull/2458
> >
> >   Documentation/config/status.adoc | 11 ++++++-----
> >   remote.c                         |  1 +
> >   t/t5505-remote.sh                |  1 -
> >   t/t6040-tracking-info.sh         | 30 +++++++++++++++---------------
> >   4 files changed, 22 insertions(+), 21 deletions(-)
> >
> > diff --git a/Documentation/config/status.adoc b/Documentation/config/status.adoc
> > index b5dd85b761..1d847d3a8a 100644
> > --- a/Documentation/config/status.adoc
> > +++ b/Documentation/config/status.adoc
> > @@ -23,8 +23,9 @@ status.compareBranches::
> >       are supported. They are interpreted as `branch@{upstream}` and
> >       `branch@{push}` for the current branch.
> >   +
> > -If not set, the default behavior is equivalent to `@{upstream}`, which
> > -compares against the configured upstream tracking branch.
> > +If not set, the default behavior is equivalent to `@{upstream} @{push}`,
> > +which compares against both the configured upstream and push tracking
> > +branches.
> >   +
> >   The entries are shown in the order they appear in the configuration.
> >   Duplicate entries that resolve to the same ref are suppressed after
> > @@ -36,11 +37,11 @@ Example:
> >   +
> >   ----
> >   [status]
> > -     compareBranches = @{upstream} @{push}
> > +     compareBranches = @{upstream}
> >   ----
> >   +
> > -This would show comparisons against both the configured upstream and push
> > -tracking branches for the current branch.
> > +This would only show the comparison against the configured upstream
> > +tracking branch for the current branch.
> >
> >   status.displayCommentPrefix::
> >       If set to true, linkgit:git-status[1] will insert a comment
> > diff --git a/remote.c b/remote.c
> > index 71170f36a9..6fdb4b84da 100644
> > --- a/remote.c
> > +++ b/remote.c
> > @@ -2465,6 +2465,7 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb,
> >               string_list_remove_empty_items(&branches, 0);
> >       } else {
> >               string_list_append(&branches, "@{upstream}");
> > +             string_list_append(&branches, "@{push}");
> >       }
> >
> >       upstream_ref = branch_get_upstream(branch, NULL);
> > diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
> > index 5fbfcb0848..f77753605f 100755
> > --- a/t/t5505-remote.sh
> > +++ b/t/t5505-remote.sh
> > @@ -34,7 +34,6 @@ setup_url_pushremote () {
> >               git checkout -b topic --track origin/main &&
> >               git commit --allow-empty -m topic-change &&
> >               git config push.default current &&
> > -             git config status.compareBranches "@{upstream} @{push}" &&
> >               git config branch.topic.pushRemote "$fork_url" &&
> >               git push
> >       )
> > diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
> > index e95d420972..e10cde090d 100755
> > --- a/t/t6040-tracking-info.sh
> > +++ b/t/t6040-tracking-info.sh
> > @@ -331,19 +331,6 @@ test_expect_success 'status.compareBranches deduplicates when upstream and push
> >       test_cmp expect actual
> >   '
> >
> > -test_expect_success 'status.compareBranches with only upstream shows only upstream' '
> > -     test_config -C test status.compareBranches "@{upstream}" &&
> > -     git -C test checkout main &&
> > -     git -C test status >actual &&
> > -     cat >expect <<-EOF &&
> > -     On branch main
> > -     Your branch is up to date with ${SQ}origin/main${SQ}.
> > -
> > -     nothing to commit, working tree clean
> > -     EOF
> > -     test_cmp expect actual
> > -'
> > -
> >   test_expect_success 'status.compareBranches with only push shows only push' '
> >       test_config -C test push.default current &&
> >       test_config -C test status.compareBranches "@{push}" &&
> > @@ -361,9 +348,8 @@ test_expect_success 'status.compareBranches with only push shows only push' '
> >       test_cmp expect actual
> >   '
> >
> > -test_expect_success 'status.compareBranches shows ahead of both upstream and push branch' '
> > +test_expect_success 'status shows ahead of both upstream and push branch by default' '
> >       test_config -C test push.default current &&
> > -     test_config -C test status.compareBranches "@{upstream} @{push}" &&
> >       git -C test checkout -b feature3 origin/main &&
> >       git -C test push origin HEAD &&
> >       (cd test && advance work) &&
> > @@ -380,6 +366,20 @@ test_expect_success 'status.compareBranches shows ahead of both upstream and pus
> >       test_cmp expect actual
> >   '
> >
> > +test_expect_success 'status.compareBranches with only upstream shows only upstream' '
> > +     test_config -C test push.default current &&
> > +     test_config -C test status.compareBranches "@{upstream}" &&
> > +     git -C test checkout feature3 &&
> > +     git -C test status >actual &&
> > +     cat >expect <<-EOF &&
> > +     On branch feature3
> > +     Your branch is ahead of ${SQ}origin/main${SQ} by 1 commit.
> > +
> > +     nothing to commit, working tree clean
> > +     EOF
> > +     test_cmp expect actual
> > +'
> > +
> >   test_expect_success 'checkout with status.compareBranches shows both branches' '
> >       test_config -C test push.default current &&
> >       test_config -C test status.compareBranches "@{upstream} @{push}" &&
> >
> > base-commit: c51408889c3b372814bc20b9431c3b74d0d268eb
As a side note:

I see that you include the whole message in replies, leaving responders to clean it, so more work for multiple people instead of more work for a single person. Isn't the convention to only include the parts that you are responding to?

Harald
Kristoffer Haugsbakk· Oct 20, 2026, 10:56 UTC · re: Harald Nordgren · lore

Re: [PATCH] status: compare against both upstream and push branch by default

On Tue, Oct 20, 2026, at 12:19, Harald Nordgren wrote:
Show 8 quoted lines
>> >[snip]
>
> As a side note:
>
> I see that you include the whole message in replies, leaving
> responders to clean it, so more work for multiple people instead of
> more work for a single person. Isn't the convention to only include
> the parts that you are responding to?
That’s generally recommended yes.
e.g. https://lore.kernel.org/git/arz7CNEhQSoDwJ77@pks.im/#t
Phillip Wood· Oct 20, 2026, 13:22 UTC · re: Harald Nordgren · lore

Re: [PATCH] status: compare against both upstream and push branch by default

On 20/10/2026 11:19, Harald Nordgren wrote:
Show 5 quoted lines
> > As a side note:
> > I see that you include the whole message in replies, leaving
> responders to clean it, so more work for multiple people instead of
> more work for a single person. Isn't the convention to only include
> the parts that you are responding to?
I tend not to trim the message below my signature (which indicates the end of my comments), but I do trim the context above it. I aim to leave enough context that someone reading my reply can comprehend it without needing to read the message I'm replying to. In this case the original commit message was only a couple of paragraphs and I though it was relevant context for my reply so I left it in. As a thread gets longer I'll trim earlier discussions more aggressively.
Thanks
Phillip
Harald Nordgren via GitGitGadget· Oct 21, 2026, 12:27 UTC · re: Harald Nordgren via GitGitGadget · lore

[PATCH v2] status: compare against both upstream and push branch by default

From: Harald Nordgren <haraldnordgren@gmail.com>

Commit 3ea95ac9c5 (status: add status.compareBranches config for multiple branch comparisons, 2026-02-26) added status.compareBranches so that "git status" can show comparison of the current branch with its upstream in addition to where the branch is pushed to, which is great to support the triangular workflow. It however did not make it the default to show both.

Showing both without any configuration was the original proposal for that commit. But some found the comparison with the push branch to be noise. So the comparison was made opt in [1], with the idea of flipping the default later if people like the option.

Make "@{upstream} @{push}" the default. With push.default left at "simple", @{push} is either the same as @{upstream} or does not resolve at all, so the output stays the same. It only changes for those who set push.default to "current" or "matching", or configure a push refspec, in two cases:

  - In a triangular workflow, a comparison with the push branch is
    shown after the one with the upstream.
  - A branch without an upstream is compared with the branch it is
    pushed to, where nothing was shown before.

Those who find the comparison with the push branch to be noise can set status.compareBranches to "@{upstream}" to get the old output back. Having configured push.default and a push remote to get there, they are the users best placed to find that setting. Those who are just starting to push somewhere other than where they pull from benefit the most from seeing both comparisons without having to discover the variable first.

No existing test relied on the old default, since none of them had a push branch different from the upstream without also setting status.compareBranches. Add tests for the new default on a branch whose upstream and push branch are the same, on a branch in a triangular workflow, and on a branch without an upstream. The existing test that sets the variable to "@{upstream}" uses a branch where both are the same, so it passes with either default. Add one on a triangular branch to show that it restores the old output.

[1] https://lore.kernel.org/git/xmqq8qe0f2iq.fsf@gitster.g/
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
    status: compare against both upstream and push branch by default
    
    Make @{upstream} @{push} the default for status.compareBranches. With
    the default push.default of simple the output does not change. With
    current or matching, a branch pushed somewhere other than its upstream
    now shows both comparisons.
    
    Changes in v2:
    
     * Kept the existing tests unchanged, including the explicit
       "@{upstream} @{push}" config and the "@{upstream}" test on main
     * Added tests for the new default with the same upstream and push
       branch, in a triangular workflow, and without an upstream
     * Added a test showing that "@{upstream}" restores the old output on a
       triangular branch
     * Reworded the commit message to point to 3ea95ac9c5 and explain which
       setups see a change
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2458%2FHaraldNordgren%2Fstatus-compare-branches-default-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2458/HaraldNordgren/status-compare-branches-default-v2
Pull-Request: https://github.com/git/git/pull/2458
Range-diff vs v1:
 1:  2de975c175 ! 1:  39512b9ea1 status: compare against both upstream and push branch by default
     @@ Metadata
       ## Commit message ##
          status: compare against both upstream and push branch by default
      
     -    In a triangular workflow, where a branch is pulled from one place and
     -    pushed to another, "git status" only compares the branch to its
     -    upstream. It says nothing about the branch it is pushed to unless
     -    status.compareBranches is configured.
     +    Commit 3ea95ac9c5 (status: add status.compareBranches config for
     +    multiple branch comparisons, 2026-02-26) added status.compareBranches
     +    so that "git status" can show comparison of the current branch with
     +    its upstream in addition to where the branch is pushed to, which is
     +    great to support the triangular workflow. It however did not make it
     +    the default to show both.
      
     -    Show both comparisons by default. When the two resolve to the same
     -    branch, which is the common case, only one comparison is shown, so the
     -    output for most users does not change. Setting status.compareBranches
     -    to "@{upstream}" gives the previous output.
     +    Showing both without any configuration was the original proposal for
     +    that commit. But some found the comparison with the push branch to be
     +    noise. So the comparison was made opt in [1], with the idea of
     +    flipping the default later if people like the option.
     +
     +    Make "@{upstream} @{push}" the default. With push.default left at
     +    "simple", @{push} is either the same as @{upstream} or does not
     +    resolve at all, so the output stays the same. It only changes for
     +    those who set push.default to "current" or "matching", or configure a
     +    push refspec, in two cases:
     +
     +      - In a triangular workflow, a comparison with the push branch is
     +        shown after the one with the upstream.
     +
     +      - A branch without an upstream is compared with the branch it is
     +        pushed to, where nothing was shown before.
     +
     +    Those who find the comparison with the push branch to be noise can
     +    set status.compareBranches to "@{upstream}" to get the old output
     +    back. Having configured push.default and a push remote to get there,
     +    they are the users best placed to find that setting. Those who are
     +    just starting to push somewhere other than where they pull from
     +    benefit the most from seeing both comparisons without having to
     +    discover the variable first.
     +
     +    No existing test relied on the old default, since none of them had a
     +    push branch different from the upstream without also setting
     +    status.compareBranches. Add tests for the new default on a branch
     +    whose upstream and push branch are the same, on a branch in a
     +    triangular workflow, and on a branch without an upstream. The existing
     +    test that sets the variable to "@{upstream}" uses a branch where both
     +    are the same, so it passes with either default. Add one on a
     +    triangular branch to show that it restores the old output.
     +
     +    [1] https://lore.kernel.org/git/xmqq8qe0f2iq.fsf@gitster.g/
      
          Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
      
     @@ remote.c: int format_tracking_info(struct branch *branch, struct strbuf *sb,
       
       	upstream_ref = branch_get_upstream(branch, NULL);
      
     - ## t/t5505-remote.sh ##
     -@@ t/t5505-remote.sh: setup_url_pushremote () {
     - 		git checkout -b topic --track origin/main &&
     - 		git commit --allow-empty -m topic-change &&
     - 		git config push.default current &&
     --		git config status.compareBranches "@{upstream} @{push}" &&
     - 		git config branch.topic.pushRemote "$fork_url" &&
     - 		git push
     - 	)
     -
       ## t/t6040-tracking-info.sh ##
      @@ t/t6040-tracking-info.sh: test_expect_success 'status.compareBranches deduplicates when upstream and push
       	test_cmp expect actual
       '
       
     --test_expect_success 'status.compareBranches with only upstream shows only upstream' '
     --	test_config -C test status.compareBranches "@{upstream}" &&
     --	git -C test checkout main &&
     --	git -C test status >actual &&
     --	cat >expect <<-EOF &&
     --	On branch main
     --	Your branch is up to date with ${SQ}origin/main${SQ}.
     --
     --	nothing to commit, working tree clean
     --	EOF
     --	test_cmp expect actual
     --'
     --
     - test_expect_success 'status.compareBranches with only push shows only push' '
     - 	test_config -C test push.default current &&
     - 	test_config -C test status.compareBranches "@{push}" &&
     -@@ t/t6040-tracking-info.sh: test_expect_success 'status.compareBranches with only push shows only push' '
     - 	test_cmp expect actual
     - '
     - 
     --test_expect_success 'status.compareBranches shows ahead of both upstream and push branch' '
     -+test_expect_success 'status shows ahead of both upstream and push branch by default' '
     - 	test_config -C test push.default current &&
     --	test_config -C test status.compareBranches "@{upstream} @{push}" &&
     - 	git -C test checkout -b feature3 origin/main &&
     - 	git -C test push origin HEAD &&
     - 	(cd test && advance work) &&
     ++test_expect_success 'status shows one comparison by default when upstream and push are the same' '
     ++	git -C test checkout main &&
     ++	git -C test status >actual &&
     ++	cat >expect <<-EOF &&
     ++	On branch main
     ++	Your branch is up to date with ${SQ}origin/main${SQ}.
     ++
     ++	nothing to commit, working tree clean
     ++	EOF
     ++	test_cmp expect actual
     ++'
     ++
     + test_expect_success 'status.compareBranches with only upstream shows only upstream' '
     + 	test_config -C test status.compareBranches "@{upstream}" &&
     + 	git -C test checkout main &&
      @@ t/t6040-tracking-info.sh: test_expect_success 'status.compareBranches shows ahead of both upstream and pus
       	test_cmp expect actual
       '
       
     -+test_expect_success 'status.compareBranches with only upstream shows only upstream' '
     ++test_expect_success 'status shows ahead of both upstream and push branch by default' '
     ++	test_config -C test push.default current &&
     ++	git -C test checkout feature3 &&
     ++	git -C test status >actual &&
     ++	cat >expect <<-EOF &&
     ++	On branch feature3
     ++	Your branch is ahead of ${SQ}origin/main${SQ} by 1 commit.
     ++
     ++	Your branch is ahead of ${SQ}origin/feature3${SQ} by 1 commit.
     ++	  (use "git push" to publish your local commits)
     ++
     ++	nothing to commit, working tree clean
     ++	EOF
     ++	test_cmp expect actual
     ++'
     ++
     ++test_expect_success 'status.compareBranches with only upstream hides a different push branch' '
      +	test_config -C test push.default current &&
      +	test_config -C test status.compareBranches "@{upstream}" &&
      +	git -C test checkout feature3 &&
     @@ t/t6040-tracking-info.sh: test_expect_success 'status.compareBranches shows ahea
       test_expect_success 'checkout with status.compareBranches shows both branches' '
       	test_config -C test push.default current &&
       	test_config -C test status.compareBranches "@{upstream} @{push}" &&
     +@@ t/t6040-tracking-info.sh: test_expect_success 'status.compareBranches with behind push branch and no upstr
     + 	test_cmp expect actual
     + '
     + 
     ++test_expect_success 'status shows push branch by default without upstream' '
     ++	test_config -C test push.default current &&
     ++	test_config -C test remote.pushDefault origin &&
     ++	git -C test checkout feature15 &&
     ++	git -C test status >actual &&
     ++	cat >expect <<-EOF &&
     ++	On branch feature15
     ++	Your branch is behind ${SQ}origin/feature15${SQ} by 1 commit, and can be fast-forwarded.
     ++	  (use "git pull origin feature15" to update your local branch)
     ++
     ++	nothing to commit, working tree clean
     ++	EOF
     ++	test_cmp expect actual
     ++'
     ++
     + test_expect_success 'status.compareBranches behind upstream-equals-push suggests plain pull' '
     + 	test_config -C test status.compareBranches "@{upstream} @{push}" &&
     + 	git -C test checkout -b feature16 origin/main &&
 Documentation/config/status.adoc | 11 +++---
 remote.c                         |  1 +
 t/t6040-tracking-info.sh         | 57 ++++++++++++++++++++++++++++++++
 3 files changed, 64 insertions(+), 5 deletions(-)
Show changes to 3 files +64 −5

Documentation/config/status.adoc, remote.c, t/t6040-tracking-info.sh

diff --git a/Documentation/config/status.adoc b/Documentation/config/status.adoc
index b5dd85b761..1d847d3a8a 100644
--- a/Documentation/config/status.adoc
+++ b/Documentation/config/status.adoc
@@ -23,8 +23,9 @@ status.compareBranches::
 	are supported. They are interpreted as `branch@{upstream}` and
 	`branch@{push}` for the current branch.
 +
-If not set, the default behavior is equivalent to `@{upstream}`, which
-compares against the configured upstream tracking branch.
+If not set, the default behavior is equivalent to `@{upstream} @{push}`,
+which compares against both the configured upstream and push tracking
+branches.
 +
 The entries are shown in the order they appear in the configuration.
 Duplicate entries that resolve to the same ref are suppressed after
@@ -36,11 +37,11 @@ Example:
 +
 ----
 [status]
-	compareBranches = @{upstream} @{push}
+	compareBranches = @{upstream}
 ----
 +
-This would show comparisons against both the configured upstream and push
-tracking branches for the current branch.
+This would only show the comparison against the configured upstream
+tracking branch for the current branch.
 
 status.displayCommentPrefix::
 	If set to true, linkgit:git-status[1] will insert a comment
diff --git a/remote.c b/remote.c
index 49ee2ea318..0d97cb9100 100644
--- a/remote.c
+++ b/remote.c
@@ -2472,6 +2472,7 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb,
 		string_list_remove_empty_items(&branches, 0);
 	} else {
 		string_list_append(&branches, "@{upstream}");
+		string_list_append(&branches, "@{push}");
 	}
 
 	upstream_ref = branch_get_upstream(branch, NULL);
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index e95d420972..3d61297c37 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -331,6 +331,18 @@ test_expect_success 'status.compareBranches deduplicates when upstream and push
 	test_cmp expect actual
 '
 
+test_expect_success 'status shows one comparison by default when upstream and push are the same' '
+	git -C test checkout main &&
+	git -C test status >actual &&
+	cat >expect <<-EOF &&
+	On branch main
+	Your branch is up to date with ${SQ}origin/main${SQ}.
+
+	nothing to commit, working tree clean
+	EOF
+	test_cmp expect actual
+'
+
 test_expect_success 'status.compareBranches with only upstream shows only upstream' '
 	test_config -C test status.compareBranches "@{upstream}" &&
 	git -C test checkout main &&
@@ -380,6 +392,36 @@ test_expect_success 'status.compareBranches shows ahead of both upstream and pus
 	test_cmp expect actual
 '
 
+test_expect_success 'status shows ahead of both upstream and push branch by default' '
+	test_config -C test push.default current &&
+	git -C test checkout feature3 &&
+	git -C test status >actual &&
+	cat >expect <<-EOF &&
+	On branch feature3
+	Your branch is ahead of ${SQ}origin/main${SQ} by 1 commit.
+
+	Your branch is ahead of ${SQ}origin/feature3${SQ} by 1 commit.
+	  (use "git push" to publish your local commits)
+
+	nothing to commit, working tree clean
+	EOF
+	test_cmp expect actual
+'
+
+test_expect_success 'status.compareBranches with only upstream hides a different push branch' '
+	test_config -C test push.default current &&
+	test_config -C test status.compareBranches "@{upstream}" &&
+	git -C test checkout feature3 &&
+	git -C test status >actual &&
+	cat >expect <<-EOF &&
+	On branch feature3
+	Your branch is ahead of ${SQ}origin/main${SQ} by 1 commit.
+
+	nothing to commit, working tree clean
+	EOF
+	test_cmp expect actual
+'
+
 test_expect_success 'checkout with status.compareBranches shows both branches' '
 	test_config -C test push.default current &&
 	test_config -C test status.compareBranches "@{upstream} @{push}" &&
@@ -707,6 +749,21 @@ test_expect_success 'status.compareBranches with behind push branch and no upstr
 	test_cmp expect actual
 '
 
+test_expect_success 'status shows push branch by default without upstream' '
+	test_config -C test push.default current &&
+	test_config -C test remote.pushDefault origin &&
+	git -C test checkout feature15 &&
+	git -C test status >actual &&
+	cat >expect <<-EOF &&
+	On branch feature15
+	Your branch is behind ${SQ}origin/feature15${SQ} by 1 commit, and can be fast-forwarded.
+	  (use "git pull origin feature15" to update your local branch)
+
+	nothing to commit, working tree clean
+	EOF
+	test_cmp expect actual
+'
+
 test_expect_success 'status.compareBranches behind upstream-equals-push suggests plain pull' '
 	test_config -C test status.compareBranches "@{upstream} @{push}" &&
 	git -C test checkout -b feature16 origin/main &&

base-commit: 47fdf2208c5b94c8cc01c106b8f7c85efb91c926
-- 
gitgitgadget
Junio C Hamano· Oct 23, 2026, 17:43 UTC · re: Harald Nordgren via GitGitGadget · lore

Re: [PATCH v2] status: compare against both upstream and push branch by default

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> Showing both without any configuration was the original proposal for
> that commit. But some found the comparison with the push branch to be
> noise. So the comparison was made opt in [1], with the idea of
> flipping the default later if people like the option.
The key phrase here is "if people like the option".
> Those who find the comparison with the push branch to be noise can
> set status.compareBranches to "@{upstream}" to get the old output
> back.

The presence of an escape hatch is described here. But its existence is not a valid excuse to force people to use it, nor does it answer the question "if people like the option" posed above.

The paragraph above (and below) also assumes that comparing with @{push} is not noise for many people. We have not yet heard a convincing argument supporting that assumption in the proposed log message. In a triangular workflow, @{upstream} is not under your control, so you may want to monitor its progress closely. But isn't your @{push} destination typically owned solely by you? In other words, aren't you the only one who pushes to it? If so, whatever you did locally would be the only change that could go on top of @{push}, and unlike @{upstream} you would not see any unexpected work over there appearing without your control.

Show 5 quoted lines
> Having configured push.default and a push remote to get there,
> they are the users best placed to find that setting. Those who are
> just starting to push somewhere other than where they pull from
> benefit the most from seeing both comparisons without having to
> discover the variable first.

I do not think I follow. Those who are just starting to push to a destination other than @{upstream} would have changed their configuration to do so, wouldn't they? Aren't they equally well placed, if not more, to find the same setting?

Overall, I still do not find it convincing that we should change the default to surprise existing users.

Thanks.
Harald Nordgren· Oct 23, 2026, 18:48 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] status: compare against both upstream and push branch by default

> I do not think I follow.  Those who are just starting to push to a
> destination other than @{upstream} would have changed their
> configuration to do so, wouldn't they?  Aren't they equally well
> placed, if not more, to find the same setting?

Most users (from my experience) have their *push* branch as upstream, stemming from the `git push -u` behavior that is recommended by GitHub. Meaning they are already missing the info about what upstream is doing and how it’s changing.

This is limiting their understanding of triangular workflows.

When using `--set-upstream-to`, now they get upstream status, a big improvement, but this scares many users because the connection to push branch is now seemingly lost.

This is the point behind this: To ease users into triangular thinking. We should not assume our users are git experts, many of my them never read the git docs.

Harald
Junio C Hamano· Oct 23, 2026, 22:10 UTC · re: Harald Nordgren · lore

Re: [PATCH v2] status: compare against both upstream and push branch by default

Harald Nordgren <haraldnordgren@gmail.com> writes:
> This is the point behind this: To ease users into triangular thinking.
> We should not assume our users are git experts, many of my them never
> read the git docs.

So instead we should assume that they start from mental model that was destroyed by use of GitHub? The need to do so somehow makes it smell like a sad world.

Harald Nordgren· Oct 23, 2026, 22:54 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] status: compare against both upstream and push branch by default

Show 7 quoted lines
> > This is the point behind this: To ease users into triangular thinking.
> > We should not assume our users are git experts, many of my them never
> > read the git docs.
>
> So instead we should assume that they start from mental model that
> was destroyed by use of GitHub?  The need to do so somehow makes it
> smell like a sad world.

I think it's better to accept the world as it is rather than engaging in wishful thinking :)

Harald
Junio C Hamano· Oct 23, 2026, 23:07 UTC · re: Harald Nordgren · lore

Re: [PATCH v2] status: compare against both upstream and push branch by default

Harald Nordgren <haraldnordgren@gmail.com> writes:
Show 10 quoted lines
>> > This is the point behind this: To ease users into triangular thinking.
>> > We should not assume our users are git experts, many of my them never
>> > read the git docs.
>>
>> So instead we should assume that they start from mental model that
>> was destroyed by use of GitHub?  The need to do so somehow makes it
>> smell like a sad world.
>
> I think it's better to accept the world as it is rather than engaging
> in wishful thinking :)

At least you could push whatever is encouraging the use of "-u" to break their mental model into also suggesting to set the necessary configuration, which would make _them_ internally consistent, without breaking existing users (and without bothering me).

D. Ben Knoble· Oct 24, 2026, 13:49 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] status: compare against both upstream and push branch by default

On Fri, Oct 23, 2026 at 1:45 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 17 quoted lines
>
> "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > Showing both without any configuration was the original proposal for
> > that commit. But some found the comparison with the push branch to be
> > noise. So the comparison was made opt in [1], with the idea of
> > flipping the default later if people like the option.
>
> The key phrase here is "if people like the option".
>
> > Those who find the comparison with the push branch to be noise can
> > set status.compareBranches to "@{upstream}" to get the old output
> > back.
>
> The presence of an escape hatch is described here.  But its
> existence is not a valid excuse to force people to use it, nor does
> it answer the question "if people like the option" posed above.

I agree, though I still support changing the default. I think we need to make a stronger case.

Show 10 quoted lines
> The paragraph above (and below) also assumes that comparing with
> @{push} is not noise for many people.  We have not yet heard a
> convincing argument supporting that assumption in the proposed log
> message.  In a triangular workflow, @{upstream} is not under your
> control, so you may want to monitor its progress closely.  But isn't
> your @{push} destination typically owned solely by you?  In other
> words, aren't you the only one who pushes to it?  If so, whatever
> you did locally would be the only change that could go on top of
> @{push}, and unlike @{upstream} you would not see any unexpected
> work over there appearing without your control.
I think this paragraph assumes that either
* I'm only pushing new commits to @{push}, or
* I remember what the current state of @{push} is without checking.

I may not see "unexpected" work appearing there in most cases, but I certainly appreciate the reminder when returning to a topic after working on something else. Have I rebased/amended/git-history'd lately and need to force-push? Do I care about the differences? Sometimes I already know the answer and want to validate what I'm about to send out, kind of like "git send-email" with sendemail.annotate (and multiedit, for me) configured.

I have a number of ways of helping answer this question, personally:
* git status: only ahead-behind count, but lets me know if there's
anything to do. I don't actually check this output too often myself
because I built the below prior the config under discussion, and they
are focused + finger memory---I almost always run short status when I
do look at status, but that's because I don't normally need the
verbose output these days ;) That's not the case for most of our
users.
* "git sbup" = show-branch HEAD HEAD@{push} HEAD@{upstream}: a quick
divergence check
* "git rdup" = range-diff HEAD@{upstream} HEAD@{push} HEAD: a detailed
comparison
* "git div" [1] runs a triple-dot graph log (with more options)
comparing HEAD against @{push} (if they differ) or @{upstream} (if
they're the same), omitting some other inferences and ways to supply
which topic to inspect.
[1]: https://github.com/benknoble/Dotfiles/blob/master/links/bin/git-div

So, I suppose my point is: as someone who almost exclusively has triangular workflows, I'm already checking this push--local divergence on a regular basis. I just built my own extensions to do so prior to Harald's welcome addition to status. Perhaps that can help Harald argue the case more convincingly in a proposed log message?

(Julia and I discussed briefly off-list whether "git-div"/"git-vee" should be part of Git, and I'm noodling on whether such a thing might make sense as "git log --divergence" or something.)

-- 
D. Ben Knoble
Junio C Hamano· Oct 24, 2026, 16:43 UTC · re: D. Ben Knoble · lore

Re: [PATCH v2] status: compare against both upstream and push branch by default

"D. Ben Knoble" <ben.knoble@gmail.com> writes:
Show 11 quoted lines
>> control, so you may want to monitor its progress closely.  But isn't
>> your @{push} destination typically owned solely by you?  In other
>> words, aren't you the only one who pushes to it?  If so, whatever
>> you did locally would be the only change that could go on top of
>> @{push}, and unlike @{upstream} you would not see any unexpected
>> work over there appearing without your control.
>
> I think this paragraph assumes that either
>
> * I'm only pushing new commits to @{push}, or
> * I remember what the current state of @{push} is without checking.

I do strongly assume the former (I count revert in "new commits" in this context, by the way), but not necessarily the latter. But unlike what appears in @{upstream}, I expect you would recognise them when you see them.

Harald Nordgren via GitGitGadget· Oct 25, 2026, 10:51 UTC · re: Harald Nordgren via GitGitGadget · lore

[PATCH v3] status: compare against both upstream and push branch by default

From: Harald Nordgren <haraldnordgren@gmail.com>

Commit 3ea95ac9c5 (status: add status.compareBranches config for multiple branch comparisons, 2026-02-26) added status.compareBranches so that "git status" can show comparison of the current branch with its upstream in addition to where the branch is pushed to, which is great to support the triangular workflow. It however did not make it the default to show both.

Showing both without any configuration was the original proposal for that commit. But some found the comparison with the push branch to be noise. So the comparison was made opt in [1], with the idea of flipping the default later if people like the option.

Even when nobody else pushes to the push branch, the comparison with it is useful:

  - When returning to a topic after working on something else, it is
    a reminder of how the branch differs from what was last pushed.
  - It tells whether the branch was rebased or rewritten locally since
    the last push, and needs a forced push.
  - When the answer is already known, it is a quick way to validate
    what is about to be pushed out, much like sendemail.annotate lets
    one review each patch before "git send-email" sends it.

Some who work mostly in triangular workflows check this regularly, and have built their own aliases for that: a quick check of how the branch has diverged from its push and upstream branches, a detailed comparison of what was pushed with the local version, and a graph of where the branch and its push branch diverged. Most users have no such aliases and only see what plain "git status" tells them. Showing both by default gives them that check without having to discover the variable first.

Make "@{upstream} @{push}" the default. With push.default left at "simple", @{push} is either the same as @{upstream} or does not resolve at all, so the output stays the same. It only changes for those who set push.default to "current" or "matching", or configure a push refspec, in two cases:

  - In a triangular workflow, a comparison with the push branch is
    shown after the one with the upstream.
  - A branch without an upstream is compared with the branch it is
    pushed to, where nothing was shown before.

No existing test relied on the old default, since none of them had a push branch different from the upstream without also setting status.compareBranches. Add tests for the new default on a branch whose upstream and push branch are the same, on a branch in a triangular workflow, and on a branch without an upstream. The existing test that sets the variable to "@{upstream}" uses a branch where both are the same, so it passes with either default. Add one on a triangular branch to show that it restores the old output.

[1] https://lore.kernel.org/git/xmqq8qe0f2iq.fsf@gitster.g/
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
---
    status: compare against both upstream and push branch by default
    
    Make @{upstream} @{push} the default for status.compareBranches. With
    the default push.default of simple the output does not change. With
    current or matching, a branch pushed somewhere other than its upstream
    now shows both comparisons.
    
    Changes in v3:
    
     * Try to make a stronger case in commit message.
    
    Changes in v2:
    
     * Kept the existing tests unchanged, including the explicit
       "@{upstream} @{push}" config and the "@{upstream}" test on main
     * Added tests for the new default with the same upstream and push
       branch, in a triangular workflow, and without an upstream
     * Added a test showing that "@{upstream}" restores the old output on a
       triangular branch
     * Reworded the commit message to point to 3ea95ac9c5 and explain which
       setups see a change
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2458%2FHaraldNordgren%2Fstatus-compare-branches-default-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2458/HaraldNordgren/status-compare-branches-default-v3
Pull-Request: https://github.com/git/git/pull/2458
Range-diff vs v2:
 1:  39512b9ea1 ! 1:  ae9063c16a status: compare against both upstream and push branch by default
     @@ Commit message
          noise. So the comparison was made opt in [1], with the idea of
          flipping the default later if people like the option.
      
     +    Even when nobody else pushes to the push branch, the comparison with it
     +    is useful:
     +
     +      - When returning to a topic after working on something else, it is
     +        a reminder of how the branch differs from what was last pushed.
     +
     +      - It tells whether the branch was rebased or rewritten locally since
     +        the last push, and needs a forced push.
     +
     +      - When the answer is already known, it is a quick way to validate
     +        what is about to be pushed out, much like sendemail.annotate lets
     +        one review each patch before "git send-email" sends it.
     +
     +    Some who work mostly in triangular workflows check this regularly, and
     +    have built their own aliases for that: a quick check of how the branch
     +    has diverged from its push and upstream branches, a detailed comparison
     +    of what was pushed with the local version, and a graph of where the
     +    branch and its push branch diverged. Most users have no such aliases
     +    and only see what plain "git status" tells them. Showing both by
     +    default gives them that check without having to discover the variable
     +    first.
     +
          Make "@{upstream} @{push}" the default. With push.default left at
          "simple", @{push} is either the same as @{upstream} or does not
          resolve at all, so the output stays the same. It only changes for
     @@ Commit message
            - A branch without an upstream is compared with the branch it is
              pushed to, where nothing was shown before.
      
     -    Those who find the comparison with the push branch to be noise can
     -    set status.compareBranches to "@{upstream}" to get the old output
     -    back. Having configured push.default and a push remote to get there,
     -    they are the users best placed to find that setting. Those who are
     -    just starting to push somewhere other than where they pull from
     -    benefit the most from seeing both comparisons without having to
     -    discover the variable first.
     -
          No existing test relied on the old default, since none of them had a
          push branch different from the upstream without also setting
          status.compareBranches. Add tests for the new default on a branch
 Documentation/config/status.adoc | 11 +++---
 remote.c                         |  1 +
 t/t6040-tracking-info.sh         | 57 ++++++++++++++++++++++++++++++++
 3 files changed, 64 insertions(+), 5 deletions(-)
Show changes to 3 files +64 −5

Documentation/config/status.adoc, remote.c, t/t6040-tracking-info.sh

diff --git a/Documentation/config/status.adoc b/Documentation/config/status.adoc
index b5dd85b761..1d847d3a8a 100644
--- a/Documentation/config/status.adoc
+++ b/Documentation/config/status.adoc
@@ -23,8 +23,9 @@ status.compareBranches::
 	are supported. They are interpreted as `branch@{upstream}` and
 	`branch@{push}` for the current branch.
 +
-If not set, the default behavior is equivalent to `@{upstream}`, which
-compares against the configured upstream tracking branch.
+If not set, the default behavior is equivalent to `@{upstream} @{push}`,
+which compares against both the configured upstream and push tracking
+branches.
 +
 The entries are shown in the order they appear in the configuration.
 Duplicate entries that resolve to the same ref are suppressed after
@@ -36,11 +37,11 @@ Example:
 +
 ----
 [status]
-	compareBranches = @{upstream} @{push}
+	compareBranches = @{upstream}
 ----
 +
-This would show comparisons against both the configured upstream and push
-tracking branches for the current branch.
+This would only show the comparison against the configured upstream
+tracking branch for the current branch.
 
 status.displayCommentPrefix::
 	If set to true, linkgit:git-status[1] will insert a comment
diff --git a/remote.c b/remote.c
index 49ee2ea318..0d97cb9100 100644
--- a/remote.c
+++ b/remote.c
@@ -2472,6 +2472,7 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb,
 		string_list_remove_empty_items(&branches, 0);
 	} else {
 		string_list_append(&branches, "@{upstream}");
+		string_list_append(&branches, "@{push}");
 	}
 
 	upstream_ref = branch_get_upstream(branch, NULL);
diff --git a/t/t6040-tracking-info.sh b/t/t6040-tracking-info.sh
index e95d420972..3d61297c37 100755
--- a/t/t6040-tracking-info.sh
+++ b/t/t6040-tracking-info.sh
@@ -331,6 +331,18 @@ test_expect_success 'status.compareBranches deduplicates when upstream and push
 	test_cmp expect actual
 '
 
+test_expect_success 'status shows one comparison by default when upstream and push are the same' '
+	git -C test checkout main &&
+	git -C test status >actual &&
+	cat >expect <<-EOF &&
+	On branch main
+	Your branch is up to date with ${SQ}origin/main${SQ}.
+
+	nothing to commit, working tree clean
+	EOF
+	test_cmp expect actual
+'
+
 test_expect_success 'status.compareBranches with only upstream shows only upstream' '
 	test_config -C test status.compareBranches "@{upstream}" &&
 	git -C test checkout main &&
@@ -380,6 +392,36 @@ test_expect_success 'status.compareBranches shows ahead of both upstream and pus
 	test_cmp expect actual
 '
 
+test_expect_success 'status shows ahead of both upstream and push branch by default' '
+	test_config -C test push.default current &&
+	git -C test checkout feature3 &&
+	git -C test status >actual &&
+	cat >expect <<-EOF &&
+	On branch feature3
+	Your branch is ahead of ${SQ}origin/main${SQ} by 1 commit.
+
+	Your branch is ahead of ${SQ}origin/feature3${SQ} by 1 commit.
+	  (use "git push" to publish your local commits)
+
+	nothing to commit, working tree clean
+	EOF
+	test_cmp expect actual
+'
+
+test_expect_success 'status.compareBranches with only upstream hides a different push branch' '
+	test_config -C test push.default current &&
+	test_config -C test status.compareBranches "@{upstream}" &&
+	git -C test checkout feature3 &&
+	git -C test status >actual &&
+	cat >expect <<-EOF &&
+	On branch feature3
+	Your branch is ahead of ${SQ}origin/main${SQ} by 1 commit.
+
+	nothing to commit, working tree clean
+	EOF
+	test_cmp expect actual
+'
+
 test_expect_success 'checkout with status.compareBranches shows both branches' '
 	test_config -C test push.default current &&
 	test_config -C test status.compareBranches "@{upstream} @{push}" &&
@@ -707,6 +749,21 @@ test_expect_success 'status.compareBranches with behind push branch and no upstr
 	test_cmp expect actual
 '
 
+test_expect_success 'status shows push branch by default without upstream' '
+	test_config -C test push.default current &&
+	test_config -C test remote.pushDefault origin &&
+	git -C test checkout feature15 &&
+	git -C test status >actual &&
+	cat >expect <<-EOF &&
+	On branch feature15
+	Your branch is behind ${SQ}origin/feature15${SQ} by 1 commit, and can be fast-forwarded.
+	  (use "git pull origin feature15" to update your local branch)
+
+	nothing to commit, working tree clean
+	EOF
+	test_cmp expect actual
+'
+
 test_expect_success 'status.compareBranches behind upstream-equals-push suggests plain pull' '
 	test_config -C test status.compareBranches "@{upstream} @{push}" &&
 	git -C test checkout -b feature16 origin/main &&

base-commit: 7e34d8174dcda3435d1404c9a30bef46afe6c13e
-- 
gitgitgadget

← back to recent threads