drawing showing git history made in gimp

So I have a bug fix (green) and owner also made a bug fix (red) but I would like to rework both of them due to discussion we had. I have opened a PR and there is merge conflict that can’t be resolved. Should I open a new branch in my fork and close PR or should I google some rebase magic to apply commits to my bug-fix branch.

  • emptyother@programming.dev
    link
    fedilink
    arrow-up
    13
    ·
    1 year ago

    If the merge is really too complicated to easily resolve, drop the PR. Then you can pull in latest and make the fix anew. Don’t delete your old PR’s branch yet, you might want to look up how you did your original fix.

    • Ludrol@szmer.infoOP
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      The red commit made changes to files that after the merge would produce dead code.

      • themoonisacheese@sh.itjust.works
        link
        fedilink
        arrow-up
        4
        ·
        edit-2
        1 year ago

        Part of doing a merge commit at all is ensuring the merge results in clean code. You would need to resolve this in your merge commit, even if that area of the code was not in a merge conflict. You learn this when learning to resolve merge conflicts.

    • glad_cat@lemmy.sdf.org
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Yep, most merge conflicts that happen on less than 10 lines can be fixed manually. It’s an invaluable skill.

  • nous@programming.dev
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    It depends - as with any real answer to a problem. I would likely start with a rebase of you bug-fix on 2.0, resolve any conflicts that might have. If there are multiple commits on bug-fix I might squash them to make the merge easier. But if the conflicts are too complex to really resolve it might be easier and quicker to just redo the work in a new branch if the changes are not that big.

    Which was is better for you depends on how big those merge conflicts are. But it seems like a good opportunity to learn how to rebase and how to resolve merge conflicts.

  • LetterboxPancake@sh.itjust.works
    link
    fedilink
    Deutsch
    arrow-up
    3
    ·
    edit-2
    1 year ago

    I’d pull their main, rebase your 2.0 to theirs and then rebase your fix to your 2.0. Then you should have a better view on what has changed between those two. It’ll probably result in you cherry picking from your fix.

    • Ludrol@szmer.infoOP
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      Why?

      merge resolution would produce more work than opening new PR (couple dozen of lines of code)[I want to learn on small mistakes not on big ones] I would like to rework the owners bug fix to have cleaner code.

      Political issue

      So I should make a consensus on „Who should make the work?” and „How should feature be implemented?”.

      Sadly „2.0” is the trunk and „master” is 1.0 release but thanks for the link