Hey, if there are any folks here involved in friendly forks of fediverse software - Do you use any fancy merge strategies to merge upstream changes into your fork? What’s your mileage?

I’ve been hacking away at a private lil fork of Pleroma, adding some little convenience features for myself, and thought it might be a good idea to ask if I should be doing any of the fancy stuff github describes in their article about friendly fork management, or if I’ll be alright just doing git merge upstream/develop :^)

  • thisisawayoflife@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    1 year ago

    You would never just merge into upstream. You need to make sure your fork is up to date and there are no code conflicts, then you create a pull request from your branch into the branch you would want to merge into. That information will probably be in the specific projects contribution document.

    • feathers@kbin.cafeOP
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      1 year ago

      Oh, no, haha, I didn’t mean merging my changes into upstream! I meant merging upstream changes into my fork :p
      edit: changed wording in my post so it’s a bit more clear what I mean~

      • thisisawayoflife@lemmy.world
        link
        fedilink
        English
        arrow-up
        4
        ·
        1 year ago

        Oh gotcha! Yeah, git merge upstreamNane branchName is the right method. Just be aware that you might have a whole host of conflicts to resolve if there’s been a significant amount of time in your branch.

        One thing I like doing is creating a feature branch, then branching off that for very specific feature work. Then I try to complete that feature quickly and merge that into my feature branch and keep that up to date every day with the updated branch it was forked from. That way, I’m never too far behind production changes and the merge conflicts are kept at a minimum.

        • abruptly8951@lemmy.world
          link
          fedilink
          English
          arrow-up
          4
          ·
          1 year ago

          You need rebase instead. Merge just creates useless commits and makes the diffs harder to comprehend (all changes are shown at once, but with rebase you fix the conflicts in the commit where they happened)

          Then instead of your branch of branch strat you just rebase daily into main and you’re golden when it comes time to PR

          • feathers@kbin.cafeOP
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            1 year ago

            You need rebase instead.

            Yep yep, that’s what I do for my feature branches! ;)
            Or, well, at least when I’m the only one working on them, anyway~

            when it comes time to PR

            Oh haha, I really doubt I need to worry about that; these are pretty community-specific features, I doubt the upstream project would even want them. I am concerned only with keeping my fork’s main development branch up to date with the upstream’s. Y’know, after I merge my custom features into it. There seem to be a bunch of intricate ways to do it (see the blogpost I linked), and I’m unsure if I should care about any of those, or if I can get away with just, doing a normal merge.