Re: git push doesn't use local branch name as default

[Felipe Contreras <felipe.contreras@gmail.com>]

Elijah Newren wrote:
> On Fri, May 28, 2021 at 10:22 AM Felipe Contreras
> <felipe.contreras@gmail.com> wrote:

> > Perhaps:
> >
> > --- a/Documentation/config/push.txt
> > +++ b/Documentation/config/push.txt
> > @@ -29,8 +29,8 @@ push.default::
> >    different from the local one.
> >  +
> >  When pushing to a remote that is different from the remote you normally
> > -pull from, work as `current`.  This is the safest option and is suited
> > -for beginners.
> > +pull from (typically "origin"), work as `current`.  This is the safest option
> > +and is suited for beginners.
> 
> This is certainly an improvement.  I wonder if it might still be
> considered ambiguous or hard to parse, though.

I am sure it is, just like plenty of the official documentation.

> If so, maybe something like:
> 
> If you have a default remote configured for the current branch

This is still very hard to parse, especially since there's no command to
"configure the remote of a branch" (AFAIK).

> and are pushing to a remote other than that one

And you've lost me.

I have to do a mental model of what's trying to be said:

  x && pushed != x

If x is nil, then I can't push to it, so this is the same as:

  pushed != x

> (or if you have no default remote configured and are pushing to a
> remote other than 'origin'),

So:

  !x && pushed != 'origin'

Altogether:

  (pushed != x) || (!x && pushed != 'origin')

So:

  pushed != (x || 'origin')

And we can use an x that is more friendly to users (and there are
commands to set it):

  If you are pushing to a remote that is not the same as the upstream
  branch, or 'origin'...

> then work as 'current'.

And now I have to read what `current` is.

The current documentation is trying to replicate what the convoluted
code is doing, your version is a little better, but not by much.


This is much more straightforward:

  pushes the current branch with the same name on the remote.

  If you are working on a centralized workflow--pushing to the same
  repository you pull from (typically `origin`)--then you need to
  configure an upstream branch with the same name.

When you describe the situation clearly (and not simply transcribe the
code), it becomes clear why users like Mathias don't see the current
behavior as sane.

I'm working on some patches so the issue becomes clear for those who
don't speak user.

Cheers.

-- 
Felipe Contreras