threads / discuss / 50014

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

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

## tl;dr

3 messages between Dec 12, 2018 and Dec 12, 2018.

replies: 2people: 2as markdown or json

Sergey Organov· Dec 12, 2018, 07:15 UTC · lore
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
Junio C Hamano· Dec 12, 2018, 09:48 UTC · re: Sergey Organov · lore

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

Sergey Organov <sorganov@gmail.com> writes:
Show 5 quoted lines
> 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"?

Sergey Organov· Dec 12, 2018, 11:18 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 11 quoted lines
> 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

← back to recent threads