Hi Josh,
Your workflow makes sense to me. I personally use interactive rebase
(git rebase -i) and resolve merge conflicts along the way with git
mergetool. It works well for me. I don't see anything wrong with using
cherry-pick either -- as Jason says, both options are reasonable.
For our customizations, I've found it useful to add a prefix to the
commit message: "(sitka)" for local changes, "(sitka-backport)" for
backported bugfixes that aren't available in our current version of
Evergreen. This makes it easier to figure out which customizations you
ought to keep when you rebase, and which ones you can skip because
they're included in the version you are upgrading to.
I've also found it helpful to keep our commits fairly atomic, e.g. by
breaking up large changes into several smaller commits. This helps to
avoid headaches when there are merge conflicts.
If you have local customizations that are really bugfixes or features
that would be useful to other Evergreen users, I recommend getting those
included in the main Evergreen codebase if you can. It saves work in
the long run (ask me how I know!), and the rest of the community gets
the benefit of your improvements. :)
Good luck!
Jeff
On 2022-12-12 5:45 AM, Josh Stompro via Evergreen-dev wrote:
Hello, I'm just getting my workflow figured out and wanted to see if I'm
on the right track.
I've found all our local customizations and added them as various
commits to the release that we are on.
Then I created a new branch based on remotes/origin/tags/rel_3_9_0, and
cherry picked all the commits to that branch that I wanted. I just
called it rel_3_9_0-larl. That seemed to work just fine when I ran
through the install processes.
Then I was reading up on git rebase. So I created a new branch based on
rel_3_9_0-larl, called it rel_3_10_0-larl. Then I ran "git
rebase remotes/origin/tags/rel_3_10_0". I skipped the first few commits
that conflicted over changing the release number, and a few that were
already applied to 3_10_0. But that was way simpler than cherry picking.
Is this a reasonable approach? Are there any notable problems that I
may run into with this method?
Thanks
Josh
Company logo
*Josh Stompro*
IT Director
[email protected] <mailto:[email protected]>| 218-233-3757
ext. 139| 218-790-2110
*Lake Agassiz Regional Library *
118 5th ST S
Moorhead MN 56560
www.larl.org <http://www.larl.org>
/Our mission is to enrich lives and strengthen communities./
_______________________________________________
Evergreen-dev mailing list
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
_______________________________________________
Evergreen-dev mailing list
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
