Git development
 help / color / mirror / Atom feed
* [PATCH] status: compare against both upstream and push branch by default
@ 2026-10-19 19:23 Harald Nordgren via GitGitGadget
  2026-10-19 22:54 ` Junio C Hamano
  2026-10-20  9:33 ` Phillip Wood
  0 siblings, 2 replies; 7+ messages in thread
From: Harald Nordgren via GitGitGadget @ 2026-10-19 19:23 UTC (permalink / raw)
  To: git; +Cc: Harald Nordgren, Harald Nordgren

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(-)

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

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] status: compare against both upstream and push branch by default
  2026-10-19 19:23 [PATCH] status: compare against both upstream and push branch by default Harald Nordgren via GitGitGadget
@ 2026-10-19 22:54 ` Junio C Hamano
  2026-10-20  9:16   ` Harald Nordgren
  2026-10-20  9:33 ` Phillip Wood
  1 sibling, 1 reply; 7+ messages in thread
From: Junio C Hamano @ 2026-10-19 22:54 UTC (permalink / raw)
  To: Harald Nordgren via GitGitGadget; +Cc: git, Harald Nordgren

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

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

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

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

> +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
> +'


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] status: compare against both upstream and push branch by default
  2026-10-19 22:54 ` Junio C Hamano
@ 2026-10-20  9:16   ` Harald Nordgren
  0 siblings, 0 replies; 7+ messages in thread
From: Harald Nordgren @ 2026-10-20  9:16 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Harald Nordgren via GitGitGadget, git

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

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

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] status: compare against both upstream and push branch by default
  2026-10-19 19:23 [PATCH] status: compare against both upstream and push branch by default Harald Nordgren via GitGitGadget
  2026-10-19 22:54 ` Junio C Hamano
@ 2026-10-20  9:33 ` Phillip Wood
  2026-10-20 10:19   ` Harald Nordgren
  1 sibling, 1 reply; 7+ messages in thread
From: Phillip Wood @ 2026-10-20  9:33 UTC (permalink / raw)
  To: Harald Nordgren via GitGitGadget, git; +Cc: Harald Nordgren

Hi Harald

On 19/10/2026 20:23, Harald Nordgren via GitGitGadget wrote:
> 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


> 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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] status: compare against both upstream and push branch by default
  2026-10-20  9:33 ` Phillip Wood
@ 2026-10-20 10:19   ` Harald Nordgren
  2026-10-20 10:56     ` Kristoffer Haugsbakk
  2026-10-20 13:22     ` Phillip Wood
  0 siblings, 2 replies; 7+ messages in thread
From: Harald Nordgren @ 2026-10-20 10:19 UTC (permalink / raw)
  To: phillip.wood; +Cc: Harald Nordgren via GitGitGadget, git

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

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] status: compare against both upstream and push branch by default
  2026-10-20 10:19   ` Harald Nordgren
@ 2026-10-20 10:56     ` Kristoffer Haugsbakk
  2026-10-20 13:22     ` Phillip Wood
  1 sibling, 0 replies; 7+ messages in thread
From: Kristoffer Haugsbakk @ 2026-10-20 10:56 UTC (permalink / raw)
  To: Harald Nordgren, Phillip Wood; +Cc: git, GGG

On Tue, Oct 20, 2026, at 12:19, Harald Nordgren wrote:
>> >[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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] status: compare against both upstream and push branch by default
  2026-10-20 10:19   ` Harald Nordgren
  2026-10-20 10:56     ` Kristoffer Haugsbakk
@ 2026-10-20 13:22     ` Phillip Wood
  1 sibling, 0 replies; 7+ messages in thread
From: Phillip Wood @ 2026-10-20 13:22 UTC (permalink / raw)
  To: Harald Nordgren, phillip.wood
  Cc: Harald Nordgren via GitGitGadget, git, Kristoffer Haugsbakk

On 20/10/2026 11:19, Harald Nordgren wrote:
> 
> 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2026-10-20 13:22 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-19 19:23 [PATCH] status: compare against both upstream and push branch by default Harald Nordgren via GitGitGadget
2026-10-19 22:54 ` Junio C Hamano
2026-10-20  9:16   ` Harald Nordgren
2026-10-20  9:33 ` Phillip Wood
2026-10-20 10:19   ` Harald Nordgren
2026-10-20 10:56     ` Kristoffer Haugsbakk
2026-10-20 13:22     ` Phillip Wood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox