Testing PR's
I'm quite lost with GIT, and wondering how to include a PR to test.
For example, Miwarre has two PR's, 2231 & 2235. What GIT command do I need to issue to incorporate both of these into the latest nightly code and test?
Do you still have an unanswered question? Please log in first to post your question.
Comments
Such a set of commands would be a very good addition to the Developers' Handbook
For PR 12231
git checkout -b mgavioli-TAB_French_styles master
git pull https://github.com/mgavioli/MuseScore.git TAB_French_styles
In reply to For PR 12231 git checkout -b by [DELETED] 5
Added to the end of https://musescore.org/en/developers-handbook/git-workflow
@schepers: see also https://musescore.org/en/node/81051#comment-359616
In reply to For PR 12231 git checkout -b by [DELETED] 5
Thanks! The _name_ of the commit "TAB_French_styles" was the clue I needed, and where to find it. Once I figure this whole thing out I will be updating the GIT Workflow page with more specifics.
For now, a few more questions and comments:
1. It appears I do not need to do the initial "checkout" step as I don't want to create a local branch but just want the commit in my local codebase. This allows me to incorporate the other TAB PR as well (2235) without having two branches and MASTER.
2. Can I assume that GIT will merge two commits properly, especially those that have the same files (2231 and 2235 both have stafftypes.cpp and fonts_tablature.xml)?
3. Once I've merged what I want and compiled, how do I revert back to the normal nightly basecode?
4. Am I approaching this whole process completely the wrong way?
5. Upper/lower case of the commit name is important, isn't it? In DOS-world it's not.
In reply to Thanks! The _name_ of the by schepers
1/ You don't want to merge anything to master since master will be used to get updates. So you want to create at least another branch. branches are very cheap in git.
2/ Git will do its best. If it fails, it will ask you to solve the conflicts.
3/ See 1/.
git checkout master5/ Upper/Lower case is always important, DOS is an anomaly :-p
In reply to 1/ You don't want to merge by [DELETED] 5
1. Maybe my use case is very specific, but it seems easier if I merge into master, compile, and then revert back to master. That way I don't have any branches to manage and/or delete.
2. I thought so, it didn't complain and things seemed to work.
3. I thought it was something like that, but I've seen several different command combinations to pull the master code.
5. Well, for us Windows people, case makes no difference virtually everywhere. I asked so the instructions would be complete.
So I can approach this two ways, both seem correct. Starting from an updated master:
1. Create a local branch, call it whatever - GIT PULL whatever PR's I want -compile - revert to master - delete the branch.
or
2. GIT PULL the PR's - compile - revert back to master.
In reply to 1. Maybe my use case is very by schepers
The problem I'm running into with #1 is how do I revert to a clean master after pulling in 2231 and 2235? A 'git checkout master' shows I'm so many commits ahead of the master, but I just want to back out of the pulls.
Is this why branching is preferred?
In reply to The problem I'm running into by schepers
yes ;-)
alternative would be a git reset --hard sha-of-last-good-commit
In reply to yes ;-) alternative would be by Jojo-Schmitz
Doh, I should have thought of that! My compile script has that in there for reverting to previous commit SHA numbers, I just never thought of doing that to revert to the latest master one. Thanks, I will try that!