After creating a fork I have created two branches and made some changes and the issued a PR for each.
In the meantime a new master branch of SuiteCRM was released.
Question:
How do I align my master with the latest SuiteCRM Master. I am using gitHub only online.
Thanks!
Hi,
First, a matter of SalesAgility’s workflow:
you should have started your branches from the hotfix branch, not from master.
Then you should have made your PR directed at SuiteCRM/hotfix, not master. You can still go there and change this.
Then, about your question here:
You need to bring the branches (hotfix) in your fork up to date with SalesAgility before trying to make the PR’s. The way to do this from command-line git is part of the guide “How to Contribute to SuiteCRM”.
But from github, like you ask, sometimes it’s harder or possibly it can’t be done at all. I have recreated my fork several times (delete everything, fork again) to get this to work, but this very drastic and might not be feasible if you have more work going on in your repo. If it is possible, there is your answer.
Apart from this, to my knowledge, you can only go to the command-line. This might not be as difficult as it seems. You just need to start git somewhere (preferably Linux, but Windows is also possible), set up a remote (Salesagility), clone the project, and then you can give commands from there. This gives you full power over what you see online in Github.
@pgr
Thanks!
I’ve been playing with it today and (after trying several times) I have managed to merge the original with my fork, but then I realised that, for some reason, my fork has one commit, which is also in one of my clones which I have used for a PR.
Now I can’t figure out how to get rid of this commit, which is already in the right place, but also in the wrong one.
Additionally: what happens if I delete the fork to get a new fresh one? Do I lose my clones with their commits (in such case would I have to re-issue the PR’s)? What happens to the PR’s I have already pulled towards the original SuitCRM?
I’ll have to have a look at the command-line (but that means also spending plenty of time studying it as well as trying)
Yes, I’ve had the same problem where I fix a branch but then I can’t remove the commit that fixed the branch! Sometimes git gets really complicated. That’s why I went with the “nuclear option” a few times - delete and fork again.
When you do that, you destroy everything, except what was already merged by SalesAgility. So, to spell it out in parts:
PR’s you made in the past and were merged in salesagility/SuiteCRM, these are ok, no problem
PR’s you made in the past but are still waiting to be merged - big problem, you will mess these up if you delete your fork
fix you are currently working on so you can create a new PR: you lose this too.
So when I deleted my fork I had no pending PR’s, and I kept my current code elsewhere (normally these were simple fixes) and I had to do the commits (or edit the files) again before creating the definitive PR.
About the command-line, I did spend countless hours in the past weeks climbing the steep learning curve of git (with partial success). We can try and work out the commands together here. These things are tough, but once they’re done, they are of generic use to many people in the community. I’ll try to work on a script and post it here soon.
If you already have git set up and the remote repo’s configured (upstream being salesagility/SuiteCRM), these are the key commands:
git reset --hard upstream/hotfix
git push origin hotfix
This will wipe out anything you have done on your local hotfix branch, and make it equal to the current hotfix branch in upstream repo. Then it will push that up to your fork on github.
Now, I would like to make more complete instruction (or a script) for people who don’t have anything set up locally and who want to work from the online Github (and only occasionally). It could be done atomically, meaning, the whole script could start with nothing, clone the repo, reset hotfix, delete the local repo. It could be something like this:
mkdir TempRepo
cd TempRepo
git init
git remote add origin https://github.com/yourUser/SuiteCRM_Forked.git
git remote add upstream https://github.com/salesagility/SuiteCRM.git
git fetch upstream
git checkout hotfix
git reset --hard upstream/hotfix
git pull upstream hotfix
git push origin hotfix
cd ..
rm -R TempRepo
… but I just typed all that out without testing it! So don’t use it, or use at your own risk! I have doubts as to whether all these commands are really necessary, some might be redundant.
I am waiting for salesagility to push some changes into their branches so I can test the script with actual data.
Thanks a lot! I will try to understand and then test things on my repository to avoid causing problems.
Ok, I was making things more complicated than they are - since this is a brand new repo clone I will always have the newest branch coming in from SalesAgility, I just have to push it up to the forked repo.
This script seems to be working:
#!/bin/bash
# These point to your github forked repo of SuiteCRM:
user=yourUser
fork=SuiteCRM_Forked
echo -------
echo This script will reset a branch on a SuiteCRM fork to look exactly like the official repo.
echo It will delete any work you have on that branch in your fork.
echo "It won't delete anything on SalesAgility's repo, because you don't have the rights to push there..."
echo -------
echo 'What is the branch you want to reset (usually hotfix)? '
read theBranch
echo "Press any key to continue reset of branch $theBranch on $user/$fork"
read -rsp $'...\n' -n 1 key
mkdir TempRepo
cd TempRepo
git init
git remote add origin https://github.com/$user/$fork.git
git remote add upstream https://github.com/salesagility/SuiteCRM.git
git fetch upstream
git checkout $theBranch
git push origin $theBranch --force
cd ..
rm -R TempRepo
Remember, this is slow and inefficient because it clones the entire repo every time. The point of this approach is just to make an atomic procedure for users of Github online only to reset their branches so they can make PR’s.
That “–force” on the push command is necessary to override changes that you might have up on Github, in that same branch.
In fact, the way I tested this was
For educational reasons, you (or others!) might want to read some of these articles, my selection from the past weeks of studying this:
A great, easy to understand explanation of the conventional terms “upstream” and “origin”, and of basic git workflow:
http://thepilcrow.net/explaining-basic-concepts-git-and-github/
A more elaborate description of Git-flow, the workflow that SalesAgility uses:
http://nvie.com/posts/a-successful-git-branching-model/
An awesome and very useful Git cheatsheet (interactive, try hovering and clicking):
http://ndpsoftware.com/git-cheatsheet.html
The git manpage, for reference:
https://www.kernel.org/pub/software/scm/git/docs/
Another visual explainer, a bit more complicated but quite complete:
http://marklodato.github.io/visual-git-guide/index-en.html