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

Re: [PATCH] pull: conflict hint pull.rebase suggestion should offer "merges" vs "true"

From
Elijah Newren <newren@gmail.com>
Date
Feb 24, 2023, 23:59 UTC
Message-ID
<CABPp-BHRbKG_cXdwaPT0-Rj6QTkkJRcT4N0f45==i7oAqiTC+w@mail.gmail.com>
In-Reply-To
<87bklilnvp.fsf@osv.gnss.ru>
On Fri, Feb 24, 2023 at 2:06 PM Sergey Organov <sorganov@gmail.com> wrote:
>
> Elijah Newren <newren@gmail.com> writes:
>
> > On Wed, Feb 22, 2023 at 6:27 AM Sergey Organov <sorganov@gmail.com> wrote:
Show 10 quoted lines
> >> I also agree (in particular with Buga) that from the POV of user
> >> experience the method suggested by Phillip should be superior.
> >> [...]
> >> Even this would be a huge step forward compared to silent
> >> drop of merge commits and blindly re-merging of updated parents.
> >
> > I'm not so sure it's a huge step forward.  Or even a step forward.
>
> Git currently throws away my precious merges! Silently! How it's not a
> step forward to stop doing this?! Sorry for getting that heated :)

I totally agree with you that we have a big problem. No need to convince me on that. :-)

But having a big problem does not imply we have to implement and ship the first proposal that comes along to change things. Or second, or third. Such proposals might actually make things even worse. You correctly point out that we do not need to require perfection, but we can and should require that the proposed solutions not only make some things better but that they make things better overall.

And in order to convincingly persuade others to adopt various proposals, we should be aware of what the advantages and shortcomings are...at least the ones that have already been discovered and publicized, and be able to talk about those shortcomings candidly.

Show 5 quoted lines
> As for Dscho results specifically, I've got an impression that he never
> needed rebasing of merges in the first place, and re-merging always
> suited him just fine, so it'd be rather a surprise if rebasing of merges
> suddenly started to work better for his needs and workflows once he has
> implemented it.
Are you serious?

You're claiming the author of --preserve-merges; and the author of --rebase-merges; and someone who actually implemented the ideas you, Buga, and Phillip were all discussing to improve rebasing of merges[1]; and who maintains a project (Git for Windows) that has countless branches with hundreds of commits and myriad merge points and needs to rebase the whole lot as Git is updated...is someone who doesn't actually care about rebasing of merges?

I thought you had tried to read up on this subject and were commenting in good faith, but I'm starting to have my doubts.

Please, go read at least [1] to see Johannes comments about how the prior proposals don't work beyond simple cases. He didn't discard those ideas because he didn't care about the useful information in merge commits, he discarded them because in practice those ideas resulted in behavior that was *even worse* than the current big problems.

[1] https://lore.kernel.org/git/nycvar.QRO.7.76.6.1804130002090.65@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz/
[...]
> for now I do believe we need something
> reliable that has been checked to actually work for common cases, as
> blind re-merging simply does not.

I agree with you. The word "reliable" is particularly key, and IMO rules out any suggestion that involves applying the diff between a merge commit and either of its parents. Not only do I think it's the wrong solution theoretically, I also think they have empirically been shown to provide problems that many will consider to be as bad or worse than our current poison. I obviously don't have veto power or anything close to it, but in my opinion any solution based on those ideas do not meet the threshold bar for inclusion in Git and I'll raise my voice against them.

Solutions based on other ideas are fair game. Heck, I've proposed one and I know of simpler variants to my proposal. Other solutions may exist too. But can we stop pushing already discredited proposals and instead reach for something that has a more solid foundation?

Previous: Sergey OrganovNext: Sergey Organov
Message 17 of 34 in “pull: conflict hint pull.rebase suggestion should offer "merges" vs "true"”
  1. pull: conflict hint pull.rebase suggestion should offer "merges" vs "true"Tao Klerks via GitGitGadget, Feb 5, 2023
  2. Alex HenrieFeb 16, 2023
  3. Tao KlerksFeb 16, 2023
  4. Alex HenrieFeb 17, 2023
  5. Tao KlerksFeb 17, 2023
  6. Alex HenrieFeb 17, 2023
  7. Junio C HamanoFeb 17, 2023
  8. Elijah NewrenFeb 18, 2023
  9. Phillip WoodFeb 18, 2023
  10. Tao KlerksFeb 20, 2023
  11. Phillip WoodFeb 20, 2023
  12. Elijah NewrenFeb 20, 2023
  13. Tao KlerksFeb 21, 2023
  14. Sergey OrganovFeb 22, 2023
  15. Elijah NewrenFeb 24, 2023
  16. Sergey OrganovFeb 24, 2023
  17. Elijah NewrenFeb 24, 2023
  18. Sergey OrganovFeb 25, 2023
  19. Elijah NewrenFeb 25, 2023
  20. Sergey OrganovFeb 26, 2023
  21. Elijah NewrenFeb 27, 2023
  22. Sergey OrganovFeb 27, 2023
  23. Elijah NewrenFeb 28, 2023
  24. Elijah NewrenFeb 20, 2023
  25. Tao KlerksFeb 20, 2023
  26. Elijah NewrenFeb 20, 2023
  27. Alex HenrieFeb 20, 2023
  28. Tao KlerksFeb 21, 2023
  29. Alex HenrieFeb 21, 2023
  30. Tao KlerksFeb 21, 2023
  31. Elijah NewrenFeb 24, 2023
  32. Felipe ContrerasFeb 28, 2023
  33. Alex HenrieFeb 28, 2023
  34. Felipe ContrerasMar 1, 2023

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.