Tweet
Quite a few people have been asking about a bugfix version of 3.2.0, which doesn't include the significant and not-fully-tested changes which have gone into nightlies since xmas. Most of the devteam are pretty busy with RL right now (work, activism, babies or all of the above) so I thought it might be helpful if I pointed out how easy this would be for anyone to do using git. Then if anyone does it, it wouldn't take takk long to package and release it. EDIT: it is of course entirely takk's decision what does and doesn't get included in 3.2.1 - but I'm sure it would be appreciated if someone else took the time to go through the steps below and provide something to work with.
You do need to be comfortable with a command line - or know enough to invoke these commands in your chosen IDE. If I get this right, you shouldn't need any prior knowledge of git.
1. So, first, create yourself an account at github.com. We'll call this account yourname. You have a choice of how you configure git to allow pushing stuff to your github account - I'll assume you can make one of them work.
2. Having logged into your github account, go to http://github.com/angband/angband and click the Fork button. This will create a fork of the official repo at your github account.
3. On your local machine do "git clone git://github.com/yourname/angband dirname". This will create a local copy of your fork of the official repo in dirname.
4. Then cd into dirname and do "git checkout 3.2.0". This will take you to the exact codebase from which 3.2.0 was created, byte-for-byte. Using this command means it doesn't matter what is in the official repo when you clone it, because you're ignoring anything post-3.2.0
5. Now do "git checkout -b 3.2.1". This will create a new local branch called 3.2.1, which (for now) is a bit-for-bit copy of 3.2.0
6. Now do "git checkout origin/staging". This will take you to the staging branch which you forked and cloned - this has the very latest changes and fixes in it.
7. You then want to study the output of "git log" and make a note of the commitIDs of the fixes you want to see in 3.2.1. The commitID is the huge long ascii string at the start of each commit - but you only need to write down the first seven characters for it to be 99.999% likely to be unique. The commit messages *should* tell you which ones are bugfixes and what they fix. Do study the log carefully though, because some fixes take two or three commits before they are fully sorted. Others may be conflated with other changes (though this is bad practice on our part) - you can use "git log -p" to see the actual code changes in each commit, which may help you decide whether it's worth trying to include that commit in 3.2.1. Once you get back to xmas eve 2010, that's 3.2.0 so you can stop.
8. Once you have a list of commits you want, do "git checkout 3.2.1" to get back to your new 3.2.1 branch.
9. Then do "git cherry-pick commitID" for EACH commit that you want to include in 3.2.1, starting with the oldest and working forwards. If you get no error message, go on to the next one. If you get any kind of error, it means that your chosen commit requires something that was changed in a commit you didn't choose. If you have the skill to fix the conflict, you can do that and carry on. If not, you can use "git reset HEAD^" to wipe away the mess (then use "git log" to check which was the last successful cherry pick, and carry on from there, skipping the one that caused the problem).
10. That's it. Once you've cherry-picked all the commits you want and fixed any conflicts, you can build and test it (make distclean; ./autogen.sh; configure; make). If you can't or don't want to do that, just skip this step and one of the devteam will do it when they look at your branch. When you're finished, do "git push origin 3.2.1" to push a copy of your local 3.2.1 branch to your github repo, and post something here saying you've done it.
You do need to be comfortable with a command line - or know enough to invoke these commands in your chosen IDE. If I get this right, you shouldn't need any prior knowledge of git.
1. So, first, create yourself an account at github.com. We'll call this account yourname. You have a choice of how you configure git to allow pushing stuff to your github account - I'll assume you can make one of them work.
2. Having logged into your github account, go to http://github.com/angband/angband and click the Fork button. This will create a fork of the official repo at your github account.
3. On your local machine do "git clone git://github.com/yourname/angband dirname". This will create a local copy of your fork of the official repo in dirname.
4. Then cd into dirname and do "git checkout 3.2.0". This will take you to the exact codebase from which 3.2.0 was created, byte-for-byte. Using this command means it doesn't matter what is in the official repo when you clone it, because you're ignoring anything post-3.2.0
5. Now do "git checkout -b 3.2.1". This will create a new local branch called 3.2.1, which (for now) is a bit-for-bit copy of 3.2.0
6. Now do "git checkout origin/staging". This will take you to the staging branch which you forked and cloned - this has the very latest changes and fixes in it.
7. You then want to study the output of "git log" and make a note of the commitIDs of the fixes you want to see in 3.2.1. The commitID is the huge long ascii string at the start of each commit - but you only need to write down the first seven characters for it to be 99.999% likely to be unique. The commit messages *should* tell you which ones are bugfixes and what they fix. Do study the log carefully though, because some fixes take two or three commits before they are fully sorted. Others may be conflated with other changes (though this is bad practice on our part) - you can use "git log -p" to see the actual code changes in each commit, which may help you decide whether it's worth trying to include that commit in 3.2.1. Once you get back to xmas eve 2010, that's 3.2.0 so you can stop.
8. Once you have a list of commits you want, do "git checkout 3.2.1" to get back to your new 3.2.1 branch.
9. Then do "git cherry-pick commitID" for EACH commit that you want to include in 3.2.1, starting with the oldest and working forwards. If you get no error message, go on to the next one. If you get any kind of error, it means that your chosen commit requires something that was changed in a commit you didn't choose. If you have the skill to fix the conflict, you can do that and carry on. If not, you can use "git reset HEAD^" to wipe away the mess (then use "git log" to check which was the last successful cherry pick, and carry on from there, skipping the one that caused the problem).
10. That's it. Once you've cherry-picked all the commits you want and fixed any conflicts, you can build and test it (make distclean; ./autogen.sh; configure; make). If you can't or don't want to do that, just skip this step and one of the devteam will do it when they look at your branch. When you're finished, do "git push origin 3.2.1" to push a copy of your local 3.2.1 branch to your github repo, and post something here saying you've done it.
Comment