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

Re: Pull is Mostly Evil

From
Marc Branchaud <marcnarc@xiplink.com>
Date
May 9, 2014, 19:49 UTC
Message-ID
<536D3145.7080305@xiplink.com>
In-Reply-To
<5363BB9F.40102@xiplink.com>

After poking this hornet's nest I pretty much have stood back and not participated in the ensuing discussions. But having unleashed the hornets I feel I should at least say something, if only to assure people that I'm not ignoring their plight.

There have been various proposals to modify git-pull's defaults, and/or extend it with new configuration settings, and/or add a new command. As I don't use "git pull" I feel I'm not in any position to comment about the particulars of these proposals.

However I remain skeptical that these proposals, in any form, will really be all that helpful to new users. That's because in order to know whether or not "git pull" (or "git update") does what the user wants, the user has to understand the intricacies of both their own workflow and how git can work within that workflow. By the time a user gains that understanding, she is no longer a new user.

Still, I do think the pull command is useful. In particular I think that a project can benefit greatly by tailoring pull's behaviour to match its workflow, and that a project's participants can be told how to configure git so that pull works properly for that project. Maybe even such configuration -- a "workflow blueprint" if you will -- can be tracked inside the project itself, so that a fresh project clone can automatically have "git pull" properly configured. To me this seems like a fabulous feature for git.

But for now I go back to what I said before: Give "git pull" enough knobs to let people tailor it to their individual projects' needs. But also disable "git pull" by default, because nobody should run it until they've considered how they want it to work.

		M.
Previous: Philip Oakley
Message 50 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.