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

Re: [PATCH 0/3] Reject non-ff pulls by default

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
Sep 8, 2013, 06:17 UTC
Message-ID
<CAMP44s3U2rJsqTj4cAOpY1ntum53bEy2cP5XRNaMu5vwnYVoww@mail.gmail.com>
In-Reply-To
<20130908052107.GA15610@sigill.intra.peff.net>
On Sun, Sep 8, 2013 at 12:21 AM, Jeff King <peff@peff.net> wrote:
Show 15 quoted lines
> On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:
>
>> > It's not if you understand the difference between merge-then-commit and
>> > commit-then-merge. But for a clueless user who has been told "replace
>> > svn commit" with "git commit && git push" and replace "svn update" with
>> > "git pull", it is quite similar.
>>
>> Well, yeah, but if they are so clueless they have to be told what to
>> do, they can be told to do 'git pull --merge' instead, no?
>
> I think it's fine to tell them to do "git pull --merge". What I'd worry
> more about is somebody who is suddenly presented with the choice between
> "--rebase" and "--merge" and doesn't know which to choose. We've created a
> cognitive load on the user, and even more load if they choose --rebase
> and don't quite understand what it means.

If that happens they will go back to the guy that told them to run those commands.

Fortunately there probably are very few of these users.
> The current warning message in jc/pull-training-wheel is quite neutral
> between the two options. Perhaps we should lean more towards merging?
I don't like that message. I would like this for the deprecation period:

"The pull was not fast-forward, in the future you would have to choose a merge or a rebase, merging automatically for now. Read 'man git pull' for more help."

Then when obsolete:
The pull was not fast-forward, please either merge or rebase.

"Any more babysitting with essay long messages is counter-productive to the vast majority of Git users."

Show 5 quoted lines
> I guess that works against John's case, though, which is clueless people
> working on a project that _does_ care about the shape of history. At
> least they would have to stop and think for a moment, though, which
> might help (and maybe convince them to ask more clueful project
> members). I don't know.
Or google 'git pull' 'git merge' 'git rebase' or 'git non-fast-forward'.
-- 
Felipe Contreras
Previous: Jeff KingNext: Jeff King
Message 18 of 84 in “Reject non-ff pulls by default”
  1. 0/3 Reject non-ff pulls by defaultFelipe Contreras, Aug 31, 2013
  2. 1/3 merge: simplify ff-only optionFelipe Contreras, Aug 31, 2013
  3. 2/3 t: replace pulls with mergesFelipe Contreras, Aug 31, 2013
  4. 3/3 pull: reject non-ff pulls by defaultFelipe Contreras, Aug 31, 2013
  5. Junio C HamanoSep 3, 2013
  6. Felipe ContrerasSep 3, 2013
  7. Junio C HamanoSep 3, 2013
  8. Felipe ContrerasSep 3, 2013
  9. John KeepingSep 4, 2013
  10. Jeff KingSep 4, 2013
  11. John KeepingSep 4, 2013
  12. Felipe ContrerasSep 8, 2013
  13. Jeff KingSep 8, 2013
  14. Felipe ContrerasSep 8, 2013
  15. Jeff KingSep 8, 2013
  16. Felipe ContrerasSep 8, 2013
  17. Jeff KingSep 8, 2013
  18. Felipe ContrerasSep 8, 2013
  19. Jeff KingSep 8, 2013
  20. Felipe ContrerasSep 8, 2013
  21. Jeff KingSep 8, 2013
  22. Felipe ContrerasSep 8, 2013
  23. Jeff KingSep 9, 2013
  24. Felipe ContrerasSep 9, 2013
  25. John KeepingSep 8, 2013
  26. Jeff KingSep 9, 2013
  27. brian m. carlsonSep 8, 2013
  28. Felipe ContrerasSep 8, 2013
  29. brian m. carlsonSep 9, 2013
  30. Felipe ContrerasSep 9, 2013
  31. Felipe ContrerasSep 9, 2013
  32. brian m. carlsonSep 9, 2013
  33. Matthieu MoySep 9, 2013
  34. Junio C HamanoSep 9, 2013
  35. Jeff KingSep 9, 2013
  36. John KeepingSep 9, 2013
  37. Jeff KingSep 9, 2013
  38. John KeepingSep 9, 2013
  39. Richard HansenSep 9, 2013
  40. Matthieu MoySep 9, 2013
  41. Jeff KingSep 9, 2013
  42. Philip OakleySep 9, 2013
  43. Felipe ContrerasSep 9, 2013
  44. John KeepingSep 10, 2013
  45. Matthieu MoySep 9, 2013
  46. Junio C HamanoSep 10, 2013
  47. Felipe ContrerasSep 9, 2013
  48. Matthieu MoySep 10, 2013
  49. Felipe ContrerasSep 11, 2013
  50. Matthieu MoySep 11, 2013
  51. Felipe ContrerasSep 13, 2013
  52. Junio C HamanoSep 4, 2013
  53. Junio C HamanoSep 4, 2013
  54. Philip OakleySep 4, 2013
  55. Junio C HamanoSep 4, 2013
  56. John KeepingSep 5, 2013
  57. Junio C HamanoSep 5, 2013
  58. John KeepingSep 5, 2013
  59. Jonathan NiederSep 6, 2013
  60. Junio C HamanoSep 6, 2013
  61. John KeepingSep 7, 2013
  62. Felipe ContrerasSep 8, 2013
  63. Felipe ContrerasSep 8, 2013
  64. Philip OakleySep 8, 2013
  65. Felipe ContrerasSep 8, 2013
  66. Philip OakleySep 8, 2013
  67. Felipe ContrerasSep 8, 2013
  68. Philip OakleySep 8, 2013
  69. Philip OakleySep 8, 2013
  70. John SzakmeisterSep 5, 2013
  71. John KeepingSep 5, 2013
  72. John SzakmeisterSep 5, 2013
  73. Richard HansenSep 5, 2013
  74. Philip OakleySep 5, 2013
  75. Junio C HamanoSep 5, 2013
  76. Junio C HamanoSep 5, 2013
  77. Felipe ContrerasSep 8, 2013
  78. Richard HansenSep 8, 2013
  79. Junio C HamanoSep 8, 2013
  80. Richard HansenSep 8, 2013
  81. Philip OakleySep 8, 2013
  82. Felipe ContrerasSep 8, 2013
  83. Ramkumar RamachandraSep 8, 2013
  84. Greg TroxelSep 5, 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.