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

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

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 15, 2013, 09:29 UTC
Message-ID
<7vk3o416rq.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20130415083558.GB2278@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
Show 10 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.

The thing is, people _want_ to reuse the knowledge they have already learned to a situation it does not directly apply to, by finding a consequence, natural extension of that knowledge, applied to a new situation.

 - Your "branch.*.remote only kicks in when I do not say either what
   to push or where to push to, so 'git push -- master' won't be
   affected" could be one valid natural extension to your knowledge
   "the config only kicks in when I do not say either".
 - Peff's "'git push' chooses to push to branch.next.remote when I
   am on 'next', so 'git push -- master' run in the same state
   should also push to that place" is another equally valid natural
   extension to his knowledge that "'git push' chooses to push to
   branch.next.remote when I am on 'next'".
 - Ram's and my "branch.master.remote is about what remote my master
   branch integrates with, so no matter where I am, 'git push' that
   does not say where-to should push out my master to that remote"
   is yet another equally valid natural extension to our knowledge
   that ""branch.master.remote is about what remote my master branch
   integrates with".

I do not think it is a red-herring at all. It is not about "breaking", but "there will be multiple, conflicting and equally plausible expectations" that makes me worry about unnecessary confusion.

Previous: John KeepingNext: Ramkumar Ramachandra
Message 13 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.