git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC/PATCH] push: introduce implicit push

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Apr 15, 2013, 09:17 UTC
Message-ID
<CALkWK0kzpgucLbe5TtwbZ0st51+9ZW2hkML4=yHV4y--USfynA@mail.gmail.com>
In-Reply-To
<20130415083558.GB2278@serenity.lan>
John Keeping wrote:
Show 18 quoted lines
> I may be an atypical user, but my expectation currently is that
> branch.<name>.remote is what is used when I run "git push" with no
> additional arguments.
>
> This is probably because whenever I add additional arguments (currently)
> I have to specify where I am pushing to.
>
> So I think breaking user expectations is a red herring here because the
> current behaviour means that users cannot have any expectation of what
> will happen in this case.  Either you don't say anything and "git push"
> DTRT for your current branch or you must specify precisely what you want
> to happen (or at least the remote to use if you have push.default =
> matching or remote.<name>.mirror set).
>
> Personally I'd vote for "git push -- master" pushing to
> remote.pushdefault, but I really don't know how you handle "git push --"
> with the naïve implementation of that - is it the same as "git push" or
> "git push $(git config remote.pushdefault)"?

We're not changing, or even discussing, what a plain git push without destination or refspecs specified should do (yes, that means git push -- too); it depends on push.default, which already exists. My proposal does not aim to change the current behavior of _any_ current invocation (that means git push, git push origin master, git push next master v1.2, and so on). It aims to make the new syntax git push master +next behave logically. I think we can all agree that the logical solution (leaving aside founded/ unfounded user expectations) is to pick destinations for each of the branches specified individually. As I explained in my last email, using remote.pushdefault is Wrong because it treats branches like tags, and invents a new precedence. Voting without a basis is useless: do you have a counter-argument for the points I raised as to why it is Wrong?

Previous: John KeepingNext: John Keeping
Message 11 of 21 in “push: introduce implicit push”
  1. push: introduce implicit pushRamkumar Ramachandra, Apr 12, 2013
  2. Junio C HamanoApr 12, 2013
  3. Ramkumar RamachandraApr 13, 2013
  4. Junio C HamanoApr 14, 2013
  5. Jakub NarębskiApr 14, 2013
  6. Ramkumar RamachandraApr 14, 2013
  7. Junio C HamanoApr 15, 2013
  8. Johannes SixtApr 15, 2013
  9. Junio C HamanoApr 15, 2013
  10. John KeepingApr 15, 2013
  11. Ramkumar RamachandraApr 15, 2013
  12. John KeepingApr 15, 2013
  13. Junio C HamanoApr 15, 2013
  14. Ramkumar RamachandraApr 15, 2013
  15. John KeepingApr 15, 2013
  16. Felipe ContrerasApr 15, 2013
  17. John KeepingApr 15, 2013
  18. Felipe ContrerasApr 15, 2013
  19. Ramkumar RamachandraApr 15, 2013
  20. Jonathan NiederApr 16, 2013
  21. Jonathan NiederApr 16, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.