On Mon, Apr 5, 2010 at 10:34 AM, Stephen Kelly <steveire@xxxxxxxxx> wrote: > I want to make a 0.1 release, so that would mean creating a 0.1 branch and > updating files contained in the branch such as the README file and the CMake > files and the api documentation to report version 0.1.0, and creating the > 0.1.0 tag. The next tag on that branch would be 0.1.1 etc. Simultaneously, > the version number in those files is changes to 0.2.0 in the master branch. > > However, now I have changes in my maintenance branch (0.1) which should not > be merged into master (that is, the commits which change the version > number). > > How are you supposed to handle that with git? Simply merge and resolve the > conflict on master by keeping its version number? Am I missing some other > way of doing it here? I've used that method. it works fine, and the conflicts are only whenever the maintenance branch version number changes, which is very rare (and easy to see). As someone else suggested, doing it the way git.git does (using essentially 'git describe HEAD') is another method, though you then depend on having your source code built from the git repo unless you do even fancier stuff (like git.git does). > Additionally, I have some stuff currently in master that should not be in > the 0.1 release, but should be in the 0.2 release. If I branch and then > remove those files from the 0.1 branch, a merge will then remove them from > master too? How do I keep them on master but delete them on 0.1 and still be > able to merge from 0.1 into master? > > The only option I can think of are to do the merge, then revert the commit > sha on master that does the delete. That method will work fine. You could also squash the revert commit into your merge commit if you want, so that you never have a commit on master that has the unwanted changes. (That'll help when bisecting.) To do that, just revert using "git revert -n", then commit it with "git commit -a --amend". Have fun, Avery -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html