Minor(?) usability issue with branch.<name>.pushRemote

Minor(?) usability issue with branch.<name>.pushRemote

[Sergey Organov]

Hello,

I've got confusing behavior and the cause was somewhat hard to discover:

-- 8< --
$ git status
On branch linux
Your branch is ahead of 'vendor/jps2rin_arm' by 2 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean
$ git push
Everything up-to-date
$ git status
On branch linux
Your branch is ahead of 'vendor/jps2rin_arm' by 2 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean
$ git branch -vv
* linux  e8906f9 [vendor/jps2rin_arm: ahead 2] Linux: get rid of unused files
  master 4d1f931 [origin/master] Linux: add README and config
-- 8< --

What's going on here? Why 'git status' and 'git branch' both insist
there are 2 unpushed commits yet 'git push' does nothing? Let's try to
figure:

-- 8< --
$ git push -v
Pushing to /var/local/group/firmware/git/jps2rin
To /var/local/group/firmware/git/jps2rin
 = [up to date]      linux -> linux
updating local tracking ref 'refs/remotes/origin/linux'
Everything up-to-date
-- 8< --

So it pushes branch 'linux' to 'linux' at

/var/local/group/firmware/git/jps2rin

where everything is already published... And this push destination
doesn't match 'vendor/jps2rin_arm' to which both 'git status' and 'git
branch -vv' refer, so that's where the difference is! 

Here is actual branch configuration:

-- 8< --
$ git config --get-regexp branch[.]linux
branch.linux.remote vendor
branch.linux.merge jps2rin_arm
branch.linux.pushremote origin
branch.linux.rebase preserve
$ git remote -v
origin	/var/local/group/firmware/git/jps2rin (fetch)
origin	/var/local/group/firmware/git/jps2rin (push)
vendor	ssh://git@git/gis/Justin2 (fetch)
vendor	ssh://git@git/gis/Justin2 (push)
-- 8< --

So, finally, it's 'branch.linux.pushremote' that is the "offender".

Looks like both 'git status' and 'git branch -vv' should somehow learn
about 'branch.<name>.pushremote' feature so that their
output/suggestions make more sense?

By the way, is there a simpler/better way to print entire configuration
of a [current] branch? More human-readable? Including
"branch.<name>.description"?

$ git --version
git version 2.20.0.1.g8ad5d13

-- 
Sergey

Re: Minor(?) usability issue with branch.<name>.pushRemote

[Junio C Hamano]

Sergey Organov <sorganov@gmail.com> writes:

> So, finally, it's 'branch.linux.pushremote' that is the "offender".
>
> Looks like both 'git status' and 'git branch -vv' should somehow learn
> about 'branch.<name>.pushremote' feature so that their
> output/suggestions make more sense?

Doesn't "ahead of X by N" mean "you forked from X and built N commits
on top", not "you have N commits that is not in X which is where you
would push to"?

Re: Minor(?) usability issue with branch.<name>.pushRemote

[Sergey Organov]

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>> So, finally, it's 'branch.linux.pushremote' that is the "offender".
>>
>> Looks like both 'git status' and 'git branch -vv' should somehow learn
>> about 'branch.<name>.pushremote' feature so that their
>> output/suggestions make more sense?
>
> Doesn't "ahead of X by N" mean "you forked from X and built N commits
> on top", not "you have N commits that is not in X which is where you
> would push to"?

Sure, but the problem is that 'git status' gives exact suggestion:

 (use "git push" to publish your local commits)

that is somewhat misleading in this particular case ('git push' is now a
no-op), and then 'git branch -vv', while tells me relationship to
"upstream", keeps silence about non-matching push destination.

To add even more complexity to the case, notice that the first time
after I committed locally, the invocation of 'git push' (exactly as
suggested by 'git status') did successfully push those two commits, so
the suggestion is exactly right before the commits are pushed, yet
is rather misleading afterwards.

-- 
Sergey