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

Re: [RFC] pull/fetch rename

From
Wesley J. Landaker <wjl@icecavern.net>
Date
Oct 21, 2009, 02:01 UTC
Message-ID
<200910202001.44079.wjl@icecavern.net>
In-Reply-To
<7v7huplkyj.fsf@alter.siamese.dyndns.org>
On Tuesday 20 October 2009 17:11:32 Junio C Hamano wrote:
Show 12 quoted lines
> Thomas Rast <trast@student.ethz.ch> writes:
> > Junio C Hamano wrote:
> >> "Wesley J. Landaker" <wjl@icecavern.net> writes:
> >
> > ...
> > There would not be a configuration option.
> > ...
> >
> >> It's not even funny.
> 
> Re-read what you were responding to and notice that I was commenting on
> Wesley's proposal that _is_ about a configuration variable.
Yes, I brought up the configuration variable, not Thomas.

My main goal was to try to suggest a transition plan that would be less painful, but maybe it was actually worse. After reading Junio's response I think I agree that going down that path might be the worst of both worlds, but the basic model I was proposing (even if it's a bad idea in this case) was largely basing on (my perceived impression of) how the recent changes to push behavior were staged (i.e. with deprecation, new configuration variables, etc).

I still think that, long term, making push and pull symmetric, EITHER by 1) making push also update the working tree (in some sane way that I don't have a proposal for) or 2) making pull be just about transfering objects, not also merging (in some reasonable way that doesn't break useability, like also adding "git update" or something at the same time) would be an overall benefit.

Previous: Junio C HamanoNext: Junio C Hamano
Message 6 of 32 in “[RFC] pull/fetch rename”
  1. Thomas RastOct 20, 2009
  2. Wesley J. LandakerOct 20, 2009
  3. Junio C HamanoOct 20, 2009
  4. Thomas RastOct 20, 2009
  5. Junio C HamanoOct 20, 2009
  6. Wesley J. LandakerOct 21, 2009
  7. Junio C HamanoOct 20, 2009
  8. Nanako ShiraishiOct 20, 2009
  9. Thomas RastOct 20, 2009
  10. Daniel BarkalowOct 20, 2009
  11. Björn SteinbrinkOct 21, 2009
  12. Daniel BarkalowOct 21, 2009
  13. Björn SteinbrinkOct 21, 2009
  14. Daniel BarkalowOct 21, 2009
  15. Junio C HamanoOct 21, 2009
  16. Clemens BuchacherOct 21, 2009
  17. modernize fetch/merge/pull examplesClemens Buchacher, Oct 21, 2009
  18. Junio C HamanoOct 21, 2009
  19. git-merge: forbid fast-forward and up-to-date when --no-commit is givenJunio C Hamano, Oct 21, 2009
  20. Nanako ShiraishiOct 22, 2009
  21. Junio C HamanoOct 22, 2009
  22. git-merge: imply --no-ff when --no-commit is givenJunio C Hamano, Oct 21, 2009
  23. Clemens BuchacherOct 22, 2009
  24. Thomas RastOct 22, 2009
  25. Thomas RastOct 22, 2009
  26. Mike HommeyOct 21, 2009
  27. Junio C HamanoOct 21, 2009
  28. Mike HommeyOct 21, 2009
  29. Junio C HamanoOct 21, 2009
  30. Jeff KingOct 21, 2009
  31. Jeff KingOct 21, 2009
  32. Junio C HamanoOct 24, 2009

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.