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

Re: Considering teaching plumbing to users harmful

From
Theodore Tso <tytso@mit.edu>
Date
Jul 16, 2008, 22:32 UTC
Message-ID
<20080716223205.GK2167@mit.edu>
In-Reply-To
<7vr69tpoze.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 16, 2008 at 01:12:53PM -0700, Junio C Hamano wrote:
Show 13 quoted lines
> If you are advocating that mode of operation to be easy in git, you should
> think again.  That pull (be it with or without --rebase) can conflict and
> you would need to resolve it, and then your "stash pop" can conflict
> again.  You can have your own "git avery-up" alias which is your "svn up"
> equivalent, but if you train users with that first, the users have to
> learn how to cope with conflicts in individual steps anyway.
> 
> Making these three into a single alias is not an improvement either.  If
> you are not ready to incorporate other's changes to your history, why are
> you pulling?  Being distributed gives the power of working independently
> and at your own pace.  You should train your brain to think about the
> workflow first.  "You should stash before pull" is _not_ a good advice.
> "Do not pull when you are not ready" is.

What I've found is that some people will take that advice, and other people won't. Saying that you are thinking about things the wrong way doesn't really help for people who have been so ingrained into an old way of doing things. Indeed, it can end up sounding very elistist.

So from a pedagogical perspective, what I would probably do is show them how to replicate svn-up, and explain to them how this script works:

#!/bin/sh # git-up

if git diff --quiet && git diff --quiet --cached ; then
	git pull $*
else
	git stash ; git pull $*; git stash pop
fi

And then tell them that if this put this into their path, then "git up" will work the same way as "svn up" --- but that git has a better way of doing things, and why it is so. And then what I would tell them is that no really, merges are really easy with git, and that even if they were to rely on the "git up" alias as a crutch, that over time they would find that there are much more natural, easy, and powerful ways of doing things.

In general, I find that people are more willing to listen to "we have a more powerful way of doing things", if you can first give them the equivalent of the "dumb and stupid" way that they are used to doing things so they can switch to the new tool right away without too much of a steep learning curve; they will then switch to the more advanced/powerful workflows at their own pace. Other people may have other pedgogical techniques, but I find mine to work fairly well.

Regards,
						- Ted
Previous: Junio C HamanoNext: Junio C Hamano
Message 43 of 114 in “Considering teaching plumbing to users harmful”
  1. Johannes SchindelinJul 16, 2008
  2. Jesper EskilsonJul 16, 2008
  3. Johannes SchindelinJul 16, 2008
  4. Jesper EskilsonJul 16, 2008
  5. Johannes SchindelinJul 16, 2008
  6. Avery PennarunJul 16, 2008
  7. Johannes SchindelinJul 16, 2008
  8. Avery PennarunJul 16, 2008
  9. Theodore TsoJul 16, 2008
  10. Daniel BarkalowJul 16, 2008
  11. David KastrupJul 17, 2008
  12. Jakub NarebskiJul 17, 2008
  13. David KastrupJul 17, 2008
  14. Subversion's do-everything-via-copying paradigm ( was RE: Re: Considering teaching plumbing to users harmful)Craig L. Ching, Jul 17, 2008
  15. David KastrupJul 17, 2008
  16. Craig L. ChingJul 17, 2008
  17. Avery PennarunJul 17, 2008
  18. Junio C HamanoJul 17, 2008
  19. Jakub NarebskiJul 17, 2008
  20. Kevin BallardJul 17, 2008
  21. Petr BaudisJul 17, 2008
  22. Kevin BallardJul 17, 2008
  23. Jakub NarebskiJul 17, 2008
  24. Kevin BallardJul 17, 2008
  25. Jakub NarebskiJul 17, 2008
  26. Kevin BallardJul 17, 2008
  27. Kevin BallardJul 17, 2008
  28. David KastrupJul 17, 2008
  29. Robin RosenbergJul 17, 2008
  30. Dmitry PotapovJul 18, 2008
  31. Subversion is actually not so simple (was RE: Considering teaching plumbing to users harmful)Craig L. Ching, Jul 17, 2008
  32. Jakub NarebskiJul 17, 2008
  33. Daniel BarkalowJul 17, 2008
  34. Junio C HamanoJul 16, 2008
  35. Avery PennarunJul 16, 2008
  36. Petr BaudisJul 16, 2008
  37. Avery PennarunJul 16, 2008
  38. Junio C HamanoJul 16, 2008
  39. Avery PennarunJul 16, 2008
  40. Junio C HamanoJul 16, 2008
  41. Avery PennarunJul 16, 2008
  42. Junio C HamanoJul 16, 2008
  43. Theodore TsoJul 16, 2008
  44. Junio C HamanoJul 16, 2008
  45. Sean KelleyJul 16, 2008
  46. Nigel MagnayJul 16, 2008
  47. Stephen SinclairJul 17, 2008
  48. Ping YinJul 18, 2008
  49. Dmitry PotapovJul 16, 2008
  50. Johannes SchindelinJul 16, 2008
  51. Theodore TsoJul 16, 2008
  52. Johannes SchindelinJul 17, 2008
  53. Theodore TsoJul 17, 2008
  54. Craig L. ChingJul 17, 2008
  55. Petr BaudisJul 17, 2008
  56. J. Bruce FieldsJul 17, 2008
  57. david@lang.hmJul 16, 2008
  58. Dmitry PotapovJul 16, 2008
  59. Stephen R. van den BergJul 16, 2008
  60. Nicolas PitreJul 16, 2008
  61. Junio C HamanoJul 16, 2008
  62. Johannes SchindelinJul 16, 2008
  63. Junio C HamanoJul 16, 2008
  64. Johannes SchindelinJul 17, 2008
  65. Junio C HamanoJul 17, 2008
  66. J. Bruce FieldsJul 17, 2008
  67. Karl HasselströmJul 17, 2008
  68. Johannes SchindelinJul 17, 2008
  69. Junio C HamanoJul 17, 2008
  70. Johannes SchindelinJul 17, 2008
  71. Junio C HamanoJul 17, 2008
  72. J. Bruce FieldsJul 18, 2008
  73. Addremove equivalent [was: Re: Considering teaching plumbing to users harmful]Michael J Gruber, Jul 18, 2008
  74. Jay SoffianJul 18, 2008
  75. Johannes SchindelinJul 18, 2008
  76. Junio C HamanoJul 20, 2008
  77. 1/2 builtin-add.c: restructure the code for maintainabilityJunio C Hamano, Jul 20, 2008
  78. 2/2 git-add -a: add all filesJunio C Hamano, Jul 20, 2008
  79. 3/2 git-add -a: testsJunio C Hamano, Jul 20, 2008
  80. TarmiganJul 20, 2008
  81. TarmiganJul 20, 2008
  82. Johannes SchindelinJul 20, 2008
  83. Jay SoffianJul 20, 2008
  84. Junio C HamanoJul 20, 2008
  85. Lars NoschinskiJul 20, 2008
  86. Jeff KingJul 20, 2008
  87. Junio C HamanoJul 21, 2008
  88. Jeff KingJul 21, 2008
  89. Jeff KingJul 21, 2008
  90. Jay SoffianJul 21, 2008
  91. Sverre RabbelierJul 20, 2008
  92. Dmitry PotapovJul 16, 2008
  93. Johannes SchindelinJul 16, 2008
  94. Stephan BeyerJul 16, 2008
  95. Johannes SchindelinJul 16, 2008
  96. Stephan BeyerJul 17, 2008
  97. Peter Valdemar Mørch (Lists)Jul 17, 2008
  98. Dmitry PotapovJul 17, 2008
  99. Theodore TsoJul 17, 2008
  100. Peter Valdemar MørchJul 17, 2008
  101. Theodore TsoJul 17, 2008
  102. Junio C HamanoJul 17, 2008
  103. Andreas EricssonJul 18, 2008
  104. Jeff KingJul 18, 2008
  105. Suggestion: doc restructuring [was: Re: Considering teaching plumbing to users harmful]Michael J Gruber, Jul 18, 2008
  106. Jon LoeligerJul 18, 2008
  107. Craig L. ChingJul 18, 2008
  108. Junio C HamanoJul 18, 2008
  109. Johannes SchindelinJul 19, 2008
  110. Junio C HamanoJul 20, 2008
  111. Johannes SchindelinJul 20, 2008
  112. Andreas EricssonJul 21, 2008
  113. Johannes SchindelinJul 21, 2008
  114. Junio C HamanoJul 21, 2008

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.