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

Pull is Mostly Evil

From
Marc Branchaud <marcnarc@xiplink.com>
Date
May 2, 2014, 15:37 UTC
Message-ID
<5363BB9F.40102@xiplink.com>

(Apologies for not CCing all the folks who've participated in the "Pull is Evil" thread -- I couldn't find a good branch of that thread for this message.)

OK, so maybe "git pull" is just Mostly Evil. People seem to have found many different ways to make it work for them.

But in reality "git pull" has become a chimera that confuses a large number of new users, and that experienced users either avoid entirely or customize to give them a convenient shorthand for working in their particular environment. As a tool for new git users, it just doesn't seem to be achieving its goals.

I think the git project as a whole would benefit if it started to treat "git pull" as an advanced command, in the sense that it needs to be configured by an experienced user in order to make it correctly follow a project's workflow. Once it's configured properly, "git pull" is a powerful tool that gives users an easy way to do complex things. In that sense, it may be appropriate for a project to tailor "git pull" as it likes, then teach its own users to use the command.

However, when it comes to teaching people how to use git qua git, "git pull" should be the last thing they learn about, because it's only after you understand various basic git concepts that you can configure "git pull" to do the right thing.

To that end, I suggest that pull's default behaviour should be to do *nothing*. It should just print out a message to the effect that it hasn't been configured, and that the user should run "git help pull" for guidance.

It'll take quite a bit of time, but I think that if we change our attitude towards "git pull" and take this unconfigured-by-default approach, then in a few years the entire git ecosystem will be in a better place.

		M.
Next: David Kastrup
Message 1 of 50 in “Pull is Mostly Evil”
  1. Marc BranchaudMay 2, 2014
  2. David KastrupMay 2, 2014
  3. Philip OakleyMay 2, 2014
  4. Felipe ContrerasMay 2, 2014
  5. Philip OakleyMay 2, 2014
  6. Jonathan NiederMay 2, 2014
  7. Philip OakleyMay 3, 2014
  8. Felipe ContrerasMay 2, 2014
  9. Philip OakleyMay 3, 2014
  10. Felipe ContrerasMay 3, 2014
  11. David LangMay 2, 2014
  12. David KastrupMay 2, 2014
  13. Junio C HamanoMay 2, 2014
  14. Felipe ContrerasMay 2, 2014
  15. Junio C HamanoMay 2, 2014
  16. Felipe ContrerasMay 2, 2014
  17. Jeff KingMay 2, 2014
  18. Felipe ContrerasMay 2, 2014
  19. Jeff KingMay 2, 2014
  20. Felipe ContrerasMay 2, 2014
  21. David KastrupMay 3, 2014
  22. Junio C HamanoMay 6, 2014
  23. Felipe ContrerasMay 6, 2014
  24. Richard HansenMay 3, 2014
  25. David KastrupMay 3, 2014
  26. Felipe ContrerasMay 3, 2014
  27. David KastrupMay 3, 2014
  28. David LangMay 4, 2014
  29. Felipe ContrerasMay 4, 2014
  30. David KastrupMay 4, 2014
  31. James DenholmMay 4, 2014
  32. David KastrupMay 4, 2014
  33. Felipe ContrerasMay 4, 2014
  34. James DenholmMay 4, 2014
  35. David KastrupMay 4, 2014
  36. Felipe ContrerasMay 3, 2014
  37. Richard HansenMay 3, 2014
  38. Felipe ContrerasMay 4, 2014
  39. Richard HansenMay 4, 2014
  40. Felipe ContrerasMay 4, 2014
  41. Richard HansenMay 4, 2014
  42. Felipe ContrerasMay 4, 2014
  43. Richard HansenMay 5, 2014
  44. Felipe ContrerasMay 5, 2014
  45. Max KirillovMay 7, 2014
  46. John SzakmeisterMay 3, 2014
  47. Richard HansenMay 5, 2014
  48. Felipe ContrerasMay 5, 2014
  49. Philip OakleyMay 2, 2014
  50. Marc BranchaudMay 9, 2014

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.