So today I tried to see if i can easily automate some of my decisions. I decided that vespolina sandbox was going in a way that it was not fitting my needs and the needs of someone like me that really wants to learn about how it works, how to do things, how to extend. I think a sandbox would be open to let you develop on top of it. It is not on the contrary a repo that you can just see through the window.
In order to support my ideas I had to fork vespolina sandbox and call it newbox. So from now on I will refer to newbox. It will have the same name still but I will just call it that way because I hope others will acknowledge that some decisions on the main repo were a mistake. This is open source, and I am allowed to think different. Now how to support, back up my points and thrive?
The question then is: Now how to support, back up my points and thrive? That is the question now we are heading to answer. In order to fork and decently maintain and include only the changes from other repos that we like and at the same time keep my changes intact we have to have a way to scrutinize, cherry pick commits, and keep track of what they are and have some sort of history of rejected changes… and why not accepted changes. Yes we complicate things when we fork a main repo in the old sense of the word fork. But we have to make a point. So here we go.
I have tried to use git cola for cherry picking shas1 but it was a nightmare, so I knew it has to be done through the cli.
Analyze and Cherry Pick Flow
So the first question we can ask is really: How to realize which commits are new on the upstream branch and which commits we lack on our local master or other branch. The command below `git cherry` does that and prefixes the new commits with + sign and the missing commits on upstream with a – sign. The other parts basically cut the 3 spaces before and leave the sha1 intact for us to reverse the order of the list of shas and feed that to a git show that will show us the patch code version of each commit.
~ git cherry master upstream/master | fgrep + | cut -c3- | tac | xargs git show
To give you an idea, the output looks like:
~ git cherry master upstream/master -v --abbrev=3 - 324b Updated composer.json, dropped some bundles to make V lighter - a834 Updated dependencies & store configuration - 16ea removed unwanted files - aaa4 building with composer - 2af8 removed kernel entries for missing bundles, added scripts to composer - a2bb updated to use less files - ddd1 deleted some unwanted code - 4f8d create custom command to generate custom store - beb2b fixed command options and set defaults, threw exception for TaxonomyName not found + 43dc Updated dependencies + fb58 update composer + 1562 add Application level ProductBundle and alphabetise + 866f update composer.lock
The complete command above will give us the code to look and identify which is the sha commit we would like to cherry pick. Yes it is still a tedious one to one task with each commit we cherry-pick. So given I want to say pick `fb58` from the above example then we do:
~ git cherry-pick fb58
If there are conflicts we solved them and commit and do our homework. And then again we run the analyze command on the first section and continue with the process having now a reduced list in which there is no commit `fb58`. At the end only the rejected changes are left. So on the early stages of a fork we have a reduced number of commits left out in the cherry difference. These commits and reasons for its rejections can be well documented in several ways. One could be doing:
~ git cherry master upstream/master -v | fgrep + | cut -c3- > rejectedCommits.txt
In turn we can track rejectedCommits.txt with git.
The resolution of this would be how to filter the rejected and now annotated commits with a cli command and feed them to be explored with the git cherry command for the new acceptance cherry-pick cycle of new commits from upstream.
Until next series.
This is @cordoval and if you are hearing this you are the resistance.