git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Julia Evans" <julia@jvns.ca>
Cc: "Julia Evans" <gitgitgadget@gmail.com>,
	 git@vger.kernel.org,  "D. Ben Knoble" <ben.knoble@gmail.com>,
	 "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>
Subject: Re: [PATCH v3 4/4] doc: git-push: clarify "what to push"
Date: Fri, 26 Sep 2025 16:07:46 -0700	[thread overview]
Message-ID: <xmqqecrsak3h.fsf@gitster.g> (raw)
In-Reply-To: <2b8193d1-f492-4cfd-b568-107d68112d9a@app.fastmail.com> (Julia Evans's message of "Fri, 26 Sep 2025 18:27:00 -0400")

"Julia Evans" <julia@jvns.ca> writes:

> On Fri, Sep 26, 2025, at 3:03 PM, Junio C Hamano wrote:
>> "Julia Evans" <julia@jvns.ca> writes:
>>
>>>> In other words, the push.default=simple mode does not tell Git to
>>>> push to a branch with the same name.  Rather, as a variant of the
>>>> push.default=upstream mode, it tells Git to follow the same "push to
>>>> the upstream branch" rule, which requires you to configure your
>>>> upstream.  But the mode gives additional limit on the name of the
>>>> branch that can be set to upstream.
>>>
>>> I like the idea of explaining it as "push.default=simple uses the
>>> configured upstream branch, with the restriction that the upstream
>>> branch must have the same name".
>>>
>>> But as I learned from you earlier in this thread: https://lore.kernel.org/git/pull.1964.v2.git.1757703309.gitgitgadget@gmail.com/T/#m896f4a32ca462d69637b56f9bdfaa61e55e6b952
>>> push.default=simple will sometimes push the current branch
>>> to the remote branch with the same name even if there's no configured
>>> upstream branch.
>>
>> It was not me teaching anybody, though.  I was showing my puzzlement
>> and confusion.
>> Now, I am still confused as I was when I wrote the message you
>> cited earlier.
>>
>> Do we ever have a case where, with the "simple" mode, you have to
>> set an upstream?
>
> Yes. If you clone a repository, create a new branch, and run  `git push`
> (to push to `origin`), Git will complain that you haven’t set an upstream
> for that branch, like this:
>
>     $ git push
>     fatal: The current branch testtesttesttest has no upstream branch.
>     To push the current branch and set the remote as upstream, use
>     
>         git push --set-upstream origin testtesttesttest
>     To have this happen automatically for branches without a tracking
>     upstream, see 'push.autoSetupRemote' in 'git help config'

Hmph, that contradicts with the observation we had in the message
you cited earlier, but it does reproduce for me as well.  Puzzled
again.

> My best guess from my experimentation and from reading some
> of the commit messages/code is that the rules for how
> `push.default=simple` works are something like:
>
> 1. If the remote you're pushing to is the remote that `git pull`
>    would normally pull from if run without any arguments,
>    then require the user to set an upstream
>    (with the idea that the remote is somehow "special"
>    and should be protected from accidental pushes)

This is the traditional 'simple'


> 2. Otherwise, push to the branch to with the same name
>    without requiring an upstream to be set

This is what 'triangular' feature we saw earlier in the "git log"
output in my message you are responding to had a few commits for.

> That said, the exact details of how push.default=simple works
> (ironically) seem complicated enough that I don't think it's worth
> documenting in detail at the beginning of the `git push` man page.

Totally agreed.

> To go back to the original text I suggested:
>
>> 3. The `push.default` configuration. The default is `push.default=simple`,
>>    which will push to a branch with the same name as the current branch.
>>    See the CONFIGURATION section below for more on `push.default`.
>> 
>> As a safety measure, `git push` may fail if you haven't set an upstream
>> for the current branch, depending on what `push.default` is set to.
>> See the UPSTREAM BRANCHES section below for more on how to set and
>> use upstreams.
>
> The words "may fail" are definitely vague, and I agree it doesn't feel good
> to give a vague explanation like this. But if we think the current
> behaviour is "broken" and hard to understand and that we have to keep it for
> backwards compatibility reasons, giving a slightly vague explanation
> (perhaps with a reference to where someone can read all the gritty
> details) might be the best path.

OK.  Thanks for helping me think this through.


  reply	other threads:[~2025-09-26 23:07 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-26 20:40 [PATCH 0/4] doc: git-push: clarify DESCRIPTION section & refspec definition Julia Evans via GitGitGadget
2025-08-26 20:40 ` [PATCH 1/4] doc: git-push: update intro Julia Evans via GitGitGadget
2025-08-28 13:53   ` D. Ben Knoble
2025-08-28 16:18     ` Junio C Hamano
2025-08-29  7:20       ` Kristoffer Haugsbakk
2025-08-28 17:47     ` Julia Evans
2025-08-28 19:39       ` D. Ben Knoble
2025-08-26 20:40 ` [PATCH 2/4] doc: git-push: clarify "where to push" Julia Evans via GitGitGadget
2025-08-27  0:05   ` Junio C Hamano
2025-08-26 20:40 ` [PATCH 3/4] doc: git-push: clarify "what " Julia Evans via GitGitGadget
2025-08-26 23:57   ` Junio C Hamano
2025-08-27 13:52     ` Julia Evans
2025-08-28 14:25   ` D. Ben Knoble
2025-08-26 20:40 ` [PATCH 4/4] doc: git-push: rewrite refspec specification Julia Evans via GitGitGadget
2025-08-26 23:34   ` Junio C Hamano
2025-08-27 13:10     ` Julia Evans
2025-08-28 19:28   ` D. Ben Knoble
2025-09-12 18:55 ` [PATCH v2 0/4] doc: git-push: clarify DESCRIPTION section & refspec definition Julia Evans via GitGitGadget
2025-09-12 18:55   ` [PATCH v2 1/4] doc: git-push: clarify intro Julia Evans via GitGitGadget
2025-09-12 20:54     ` Junio C Hamano
2025-09-15 20:00       ` Julia Evans
2025-09-16  1:44         ` Junio C Hamano
2025-09-16 18:46           ` Julia Evans
2025-09-16 20:38             ` Ben Knoble
2025-09-16 21:59               ` Junio C Hamano
2025-09-17 18:42           ` Junio C Hamano
2025-09-18 14:20             ` Julia Evans
2025-09-12 18:55   ` [PATCH v2 2/4] doc: add an UPSTREAM BRANCHES section to pull/push/fetch Julia Evans via GitGitGadget
2025-09-12 21:17     ` Junio C Hamano
2025-09-15 20:19       ` Julia Evans
2025-09-15 21:48         ` Junio C Hamano
2025-09-15 23:09           ` Julia Evans
2025-09-16  5:25     ` Junio C Hamano
2025-09-16  5:33       ` Junio C Hamano
2025-09-16  5:39         ` Junio C Hamano
2025-09-18 21:02           ` Julia Evans
2025-09-12 18:55   ` [PATCH v2 3/4] doc: git-push: clarify "where to push" Julia Evans via GitGitGadget
2025-09-12 21:18     ` Junio C Hamano
2025-09-12 21:19     ` Junio C Hamano
2025-09-15 20:52       ` Julia Evans
2025-09-12 18:55   ` [PATCH v2 4/4] doc: git-push: clarify "what " Julia Evans via GitGitGadget
2025-09-23 17:44   ` [PATCH v3 0/4] doc: git-push: clarify DESCRIPTION section Julia Evans via GitGitGadget
2025-09-23 17:44     ` [PATCH v3 1/4] doc: git-push: clarify intro Julia Evans via GitGitGadget
2025-09-23 17:44     ` [PATCH v3 2/4] doc: add an UPSTREAM BRANCHES section to pull/push/fetch Julia Evans via GitGitGadget
2025-09-24 19:51       ` Junio C Hamano
2025-09-30 19:20         ` Julia Evans
2025-09-23 17:44     ` [PATCH v3 3/4] doc: git-push: clarify "where to push" Julia Evans via GitGitGadget
2025-09-23 17:44     ` [PATCH v3 4/4] doc: git-push: clarify "what " Julia Evans via GitGitGadget
2025-09-24 20:01       ` Junio C Hamano
2025-09-25 20:50         ` Julia Evans
2025-09-25 21:15           ` Junio C Hamano
2025-09-25 22:34             ` Julia Evans
2025-09-26  1:27               ` Junio C Hamano
2025-09-26 15:29                 ` Junio C Hamano
2025-09-26 17:31                   ` Julia Evans
2025-09-26 19:03                     ` Junio C Hamano
2025-09-26 22:27                       ` Julia Evans
2025-09-26 23:07                         ` Junio C Hamano [this message]
2025-09-28 21:38                           ` D. Ben Knoble
2025-09-23 17:56     ` [PATCH v3 0/4] doc: git-push: clarify DESCRIPTION section D. Ben Knoble
2025-09-30 19:58     ` [PATCH v4 0/5] " Julia Evans via GitGitGadget
2025-09-30 19:58       ` [PATCH v4 1/5] doc: git-push: clarify intro Julia Evans via GitGitGadget
2025-09-30 19:58       ` [PATCH v4 2/5] doc: add an UPSTREAM BRANCHES section to pull/push/fetch Julia Evans via GitGitGadget
2025-09-30 23:39         ` Junio C Hamano
2025-10-03 18:23           ` Julia Evans
2025-10-03 19:12             ` Junio C Hamano
2025-10-01 17:30         ` Jean-Noël AVILA
2025-10-03 17:54           ` Julia Evans
2025-09-30 19:58       ` [PATCH v4 3/5] doc: git-push: clarify "where to push" Julia Evans via GitGitGadget
2025-09-30 19:58       ` [PATCH v4 4/5] doc: git-push: clarify "what " Julia Evans via GitGitGadget
2025-09-30 21:01         ` Junio C Hamano
2025-10-01 17:36         ` Jean-Noël AVILA
2025-09-30 19:58       ` [PATCH v4 5/5] doc: git-push: Add explanation of `git push origin main` Julia Evans via GitGitGadget
2025-10-01 22:29         ` D. Ben Knoble
2025-10-03 17:58           ` Julia Evans
2025-10-01 22:28       ` [PATCH v4 0/5] doc: git-push: clarify DESCRIPTION section D. Ben Knoble
2025-10-06 18:58       ` [PATCH v5 " Julia Evans via GitGitGadget
2025-10-06 18:58         ` [PATCH v5 1/5] doc: git-push: clarify intro Julia Evans via GitGitGadget
2025-10-06 18:58         ` [PATCH v5 2/5] doc: add an UPSTREAM BRANCHES section to pull/push/fetch Julia Evans via GitGitGadget
2025-10-07 12:23           ` Kristoffer Haugsbakk
2025-10-07 13:35             ` Julia Evans
2025-10-07 18:35               ` D. Ben Knoble
2025-10-06 18:58         ` [PATCH v5 3/5] doc: git-push: clarify "where to push" Julia Evans via GitGitGadget
2025-10-06 18:58         ` [PATCH v5 4/5] doc: git-push: clarify "what " Julia Evans via GitGitGadget
2025-10-06 18:58         ` [PATCH v5 5/5] doc: git-push: Add explanation of `git push origin main` Julia Evans via GitGitGadget
2025-10-06 21:53         ` [PATCH v5 0/5] doc: git-push: clarify DESCRIPTION section D. Ben Knoble
2025-10-06 22:07         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqecrsak3h.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ben.knoble@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=julia@jvns.ca \
    --cc=kristofferhaugsbakk@fastmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).