[Evergreen-dev] Git, move local customizations to new release

[Jeff Davis]

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
> stomproj at gsuite.larl.org <mailto:stomproj at gsuite.larl.org>| 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
> Evergreen-dev at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev