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

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

From
Philip Oakley <philipoakley@iee.org>
Date
Sep 8, 2013, 08:01 UTC
Message-ID
<8B7F235220624B259BB32B293BCB3E96@PhilipOakley>
In-Reply-To
<CAMP44s1Rb2WKGD-QfNh055099R+9FHv9W8TA8Gfjp=qZh_7p7Q@mail.gmail.com>
From: "Felipe Contreras" <felipe.contreras@gmail.com>
Sent: Sunday, September 08, 2013 3:34 AM
Show 32 quoted lines
> On Thu, Sep 5, 2013 at 3:06 AM, John Keeping <john@keeping.me.uk> 
> wrote:
>> On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
>>> Are there cases where you do not want to either rebase nor merge?
>>> If so what do you want to do after "git pull" fetches from the other
>>> side?  Nothing?
>>
>> One other thing that I can see being useful occasionally is:
>>
>>     git rebase @{u}@{1} --onto @{u}
>>
>> which allows local commits to be replayed onto a rewritten upstream
>> branch.
>>
>> Although I agree with your side note below that people doing this may 
>> be
>> better off fetching and then updating their local branch, 
>> particularly
>> if @{1} is not the correct reflog entry for the upstream when they
>> created the branch.
>
> That's why after recognizing the fact the you can't find the branch
> point of a branch in Git, I decided to write patches to support the
> @{tail} shorthand, which is basically the point where the branch was
> created, or rebased to:
>
> https://github.com/felipec/git/commits/fc/base
>
> And if 'git rebase' was fixed to ignore the commits already in the
> rebased onto branch, almost always what you would want to do is 'git
> rebase @{tail} --onto @{upstream}'.
>

The use case that trips me up (i.e. doesn't fit the above) is when I have a branch that may need rebasing on (onto) pu, or may need rebasing on master, or next, depending on what others have been doing.

As a Distributed VCS (i.e. others doing work independently), a rebase always has the possibility that the world has moved on and one has to adapt to the new world order by moving location (--onto somewhere new), not just fixing up the house (patch conflicts). When the update order is unknown there is no guaranteed solution (IIUC).

You are right that mostly what one wants to do is stick with ones current location and patch up conflicts, it's just that one din't want any conflicts in the first place (i.e. the fast forward check).

Previous: Felipe ContrerasNext: Felipe Contreras
Message 64 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.