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

Re: [RFC PATCH] push: start warning upcoming default change for push.default

From
Dmitry Potapov <dpotapov@gmail.com>
Date
Mar 14, 2012, 13:23 UTC
Message-ID
<CAHkcotgMgqr29WEQfiH+89JVbTAAQyLwscXRtTyrf3JRxEuVbA@mail.gmail.com>
In-Reply-To
<vpqhaxrzh2a.fsf@bauges.imag.fr>

On Wed, Mar 14, 2012 at 1:07 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 10 quoted lines
> Dmitry Potapov <dpotapov@gmail.com> writes:
>
>> If there is a centralized workflow with only one branch then
>> everything is simple, but it is not so with other workflows.
>
> I don't get this. With either 'current' or 'upstream', both pull and
> push deal with one local and one remote branch. The only asymetry is the
> case of non-fast forward (push fails, pull merges). But it's all about
> transmitting changes from a branch to another, in one or another
> direction.

If a user has 'master' after cloning and then create another branch with different names, are you sure that the user expects that this second branch to be pushed to a remote 'master'? And then what about his stale local 'master'?

Those who understand the concept tracking may be happy with 'upstream' but when it comes to the least surprise principle for beginner , I believe 'current' is better. Maybe it would be even better if it did not create a new remote branch without asking first:

Staying on foo-branch, you do:
 $ git push
Warning: foo-branch does not exist on the remote, if you want to
create it, type: "git push foo-branch"
In this way, it will be safer.
Show 6 quoted lines
>
>> Moreover, doing 'git pull' too often (unless it is 'git pull --rebase)
>> pollutes history with useless merges, making more difficult to review
>> changes, or doing git-bisect.
>
> What's your point here? How does it invalidate the rule of thumb above?

The point is that you still need to understand what you are doing. It is not 'pull' magically resolve the problem. On the other hand, if you really want a workflow similar to CVS then you need "git pull --rebase" (you can configure 'pull' to do rebase by default, but beginners do not know about it).

BTW, whether you do merge or rebase, you still need to test the result before pushing. Even if there was no conflicts, it may not work anymore. And while you are merging and testing everything, somebody else could push his changes. So, a centralized workflow may appear simple, but it does not scale well, and often leads to many untested and hastily merged commits.

Show 6 quoted lines
>> I agree that the current diagnostic is not suitable for beginners.
>> Not-fast-forward push is something that beginners should never use,
>> but from this message is not clear what is the alternative to forcing
>> non-fast-forward push.
>
> Again, what would you suggest? Teach --force to beginners?

Not of course. I said above non-fast forward push should not be used by beginners. However, if you have branches and merge them (using 'pull' or 'merge'), it is silly pretend that they do not exist. If you happy with CVS-like behavior then just do "pull --rebase".

Show 10 quoted lines
>
>>> One can easily get in this situation even in a kernel-style workflow:
>>> work from your desktop, push, work from your laptop, try to push and it
>>> fails.
>>
>> IMHO, when you often switch between your desktop and laptop, 'matching'
>> makes much more sense.
>
> Then, if you worked on branch 'foo' from your desktop, and 'bar' on your
> laptop, you'll get errors about non-fast forward push from both machines.

Right... and then I look at the cause, and usually I have made some minor fixes to some series of patches. So when I make my mind, I do non-fast forward push, but I do not think it is how beginners should start to use 'git'.

Show 8 quoted lines
>
>> If 'push' fails then usually I want to force non- fast-forward push,
>> because the new series contain reworked patches that already were on
>> the other computer.
>
> ... but if they were not, you've just silently errased your previous
> work. I have no problem with you working like this, but please don't
> teach that to beginners.

Basically, it is same as doing 'git reset --hard somewhere'. I use it sometimes, but I have never suggested that for beginners...

Dmitry
Previous: Matthieu MoyNext: Matthieu Moy
Message 78 of 116 in “git push default behaviour?”
  1. Jeremy MortonMar 8, 2012
  2. Thomas RastMar 8, 2012
  3. Jeremy MortonMar 8, 2012
  4. Carlos Martín NietoMar 8, 2012
  5. Jeremy MortonMar 8, 2012
  6. Carlos Martín NietoMar 8, 2012
  7. Jeremy MortonMar 8, 2012
  8. Junio C HamanoMar 8, 2012
  9. Matthieu MoyMar 8, 2012
  10. Andreas KreyMar 8, 2012
  11. Junio C HamanoMar 8, 2012
  12. Matthieu MoyMar 9, 2012
  13. Junio C HamanoMar 9, 2012
  14. Jeremy MortonMar 9, 2012
  15. Matthieu MoyMar 9, 2012
  16. Jakub NarebskiMar 9, 2012
  17. Miles BaderMar 19, 2012
  18. Philippe VaucherMar 19, 2012
  19. Marc BranchaudMar 8, 2012
  20. Matthieu MoyMar 8, 2012
  21. Dmitry PotapovMar 8, 2012
  22. Matthieu MoyMar 8, 2012
  23. Jeff KingMar 9, 2012
  24. Junio C HamanoMar 9, 2012
  25. Junio C HamanoMar 9, 2012
  26. demerphqMar 9, 2012
  27. Thomas RastMar 9, 2012
  28. Junio C HamanoMar 9, 2012
  29. Gelonida NMar 16, 2012
  30. Matthieu MoyMar 9, 2012
  31. push: start warning upcoming default change for push.defaultMatthieu Moy, Mar 9, 2012
  32. Junio C HamanoMar 9, 2012
  33. Junio C HamanoMar 9, 2012
  34. Carlos Martín NietoMar 9, 2012
  35. Marc BranchaudMar 9, 2012
  36. Stefan HallerMar 9, 2012
  37. Junio C HamanoMar 10, 2012
  38. Stefan HallerMar 11, 2012
  39. Matthieu MoyMar 12, 2012
  40. Stefan HallerMar 12, 2012
  41. Matthieu MoyMar 12, 2012
  42. Junio C HamanoMar 12, 2012
  43. Marc BranchaudMar 12, 2012
  44. Michael HaggertyMar 10, 2012
  45. Marc BranchaudMar 12, 2012
  46. Matthieu MoyMar 12, 2012
  47. Junio C HamanoMar 12, 2012
  48. Jeff KingMar 12, 2012
  49. Junio C HamanoMar 12, 2012
  50. Junio C HamanoMar 12, 2012
  51. Marc BranchaudMar 12, 2012
  52. Matthieu MoyMar 13, 2012
  53. Matthieu MoyMar 13, 2012
  54. Jeff KingMar 13, 2012
  55. Junio C HamanoMar 13, 2012
  56. Jeff KingMar 14, 2012
  57. Junio C HamanoMar 14, 2012
  58. Matthieu MoyMar 13, 2012
  59. Junio C HamanoMar 13, 2012
  60. Matthieu MoyMar 13, 2012
  61. Stefan HallerMar 13, 2012
  62. Matthieu MoyMar 14, 2012
  63. Marc BranchaudMar 13, 2012
  64. Holger HellmuthMar 13, 2012
  65. Junio C HamanoMar 13, 2012
  66. Holger HellmuthMar 14, 2012
  67. Matthieu MoyMar 15, 2012
  68. Holger HellmuthMar 15, 2012
  69. Andreas EricssonMar 13, 2012
  70. Jeff KingMar 13, 2012
  71. Dmitry PotapovMar 13, 2012
  72. Junio C HamanoMar 14, 2012
  73. Dmitry PotapovMar 14, 2012
  74. Junio C HamanoMar 14, 2012
  75. Dmitry PotapovMar 14, 2012
  76. Junio C HamanoMar 14, 2012
  77. Matthieu MoyMar 14, 2012
  78. Dmitry PotapovMar 14, 2012
  79. Matthieu MoyMar 14, 2012
  80. Dmitry PotapovMar 14, 2012
  81. Matthieu MoyMar 15, 2012
  82. Michael HaggertyMar 14, 2012
  83. Jeff KingMar 14, 2012
  84. Ævar Arnfjörð BjarmasonMar 9, 2012
  85. Clemens BuchacherMar 16, 2012
  86. Matthieu MoyMar 16, 2012
  87. Junio C HamanoMar 16, 2012
  88. Matthieu MoyMar 16, 2012
  89. Clemens BuchacherMar 16, 2012
  90. Matthieu MoyMar 17, 2012
  91. Andrew MyersMar 19, 2012
  92. Junio C HamanoMar 9, 2012
  93. Matthieu MoyMar 9, 2012
  94. Junio C HamanoMar 9, 2012
  95. Junio C HamanoMar 9, 2012
  96. Jakub NarebskiMar 9, 2012
  97. Junio C HamanoMar 9, 2012
  98. Jakub NarebskiMar 13, 2012
  99. Matthieu MoyMar 12, 2012
  100. Junio C HamanoMar 12, 2012
  101. Matthieu MoyMar 13, 2012
  102. Junio C HamanoMar 13, 2012
  103. Junio C HamanoMar 16, 2012
  104. Eric HanchrowMar 17, 2012
  105. Dmitry PotapovMar 8, 2012
  106. Jakub NarebskiMar 8, 2012
  107. Jeremy MortonMar 8, 2012
  108. Jakub NarebskiMar 13, 2012
  109. Jeremy MortonMar 14, 2012
  110. Jakub NarebskiMar 14, 2012
  111. Matthieu MoyMar 8, 2012
  112. demerphqMar 8, 2012
  113. Sebastien DoucheMar 17, 2012
  114. Jeremy MortonMar 17, 2012
  115. Sebastien DoucheMar 17, 2012
  116. Pavel PospíšilMar 18, 2012

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.