So I have this exact need:

There is an upstream project doing their own thing over git and I want to build container images locally and commit them to my image repository all while following the same version system as upstream.

To be more precise (perhaps abstract) about my need, what is the best way to apply the same patch when upstream release a new version.

Any input and best practices or lessons learned are welcome.

  • pancake
    1·
    3 years ago

    If the changes are so small, I’d say you could just rebase your fork periodically, as it would generate very few conflicts.

    • dragnucsOP
      2·
      3 years ago

      I am over thinking this, but wouldn’t history be lost this way? Like If I wanted to revert to an earlier version.

      • ksynwa
        2·
        3 years ago

        You can merge instead of rebasing. That would preserve the history.

      • pancake
        1·
        3 years ago

        Ideally, both your local commits and upstream commits should remain untouched. If you want to revert either, you can rebase, revert local history or even fork your local branch.

        • dragnucsOP
          2·
          3 years ago

          Currently I have a local repository with two remotes, one is mine, the other upstream. I just had to update today So I updated upstream, cherry-picked the last commit in new release branch and pushed to main (my origin).

          But I am too lazy to keep looking for which commit to cherry-pick.

          • pancake
            3·
            3 years ago

            On your remote, I’d have a branch tracking upstream, and a fork of it with your changes. Then you can either rebase it on top of new versions or merge the main branch into your fork periodically.

            • dragnucsOP
              2·
              3 years ago

              Thanks. I am going to give this approach a try.