I have a GIT repository initially containing JUCE 4.2.3. I’ve made a lot of changes to JUCE code.
(my repository is not connected to the official JUCE repository).
I want to update JUCE to the latest version, but i don’t want to loose my changes. What is the best way to deal with it it now and for future updates?
Thx!
I’m not sure there’s an easy solution to this.
A decent three-way merge tool may help, but the best solution is (wherever possible) to modify JUCE in such a way that it’s easier to update, using derived classes in your own custom modules for example.
Isn’t this exactly what git is for? If you have your own branch in your local repo, you can pull our changes and just rebase on top of them.
Uh. of course …
Should i pull official JUCE into a separate branch of my repository - can i do that, any tip how to do it? And then do rebase?
Sorry, i don’t have a lot of experience with advanced GIT techniques, so i am a bit slow …
Thx!
There are plenty of git tutorials out there that will do a much better job of explaining it than we can!
@zabukowski, your options are:
or
I believe this article here will explain in good detail what those two options are: https://www.atlassian.com/git/tutorials/merging-vs-rebasing
Thank you - i’ll experiment with merge and rebase to see what’s the best for me.
This should help: https://robots.thoughtbot.com/keeping-a-github-fork-updated
Be aware that rebasing may induce conflicts, and you’ll need a way to deal with them.
You can also recursively rebase using all of your changes, or all of JUCE’s changes. https://stackoverflow.com/questions/2945344/how-do-i-select-a-merge-strategy-for-a-git-rebase
The other technique is to share your modifications to the community when possible.
Some people can be interested in your changes and can eventually enhance them.
Or help you find a better approach.
I do not know which the best way to do that for Juce now: forum’s talk or git pull request ?
Thx everybody for your help. Looks like rebase operation is much better option, since the number of my changed files is not very big and most of the merge conflicts are resolved automatically. Contrary, a merge operation produces a HUGE number of the unresolved conflicts.
One more question: is it necessary to resolve all conflicts at the time? For example, it would be nice if i could resolve some conflicted files, then stop work and continue work on the next day. As it looks i have to do it all one piece and then do commit - am i missing something ?!? Talking about re-basing.
Thx!
I am afraid these changes are very project specific and wouldn’t be of any use for the community.
git-imerge is designed exactly for that (haven’t got to use it myself).
Also, something that I use a lot for merging my JUCE branch changes is git-mediate.
Incredible - thank you!!!
