Stephen Kelly <steveire@xxxxxxxxx> writes: > 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? Others already have commented on this. The basic idea is avoid hardcoded versions in the tracked contents. Having said that, I do have a few instances of something similar in git.git itself: GIT-VERSION-GEN script and the RelNotes symlink that points at Documentation/RelNotes-$v.txt file. Every time I merge from maint to master after either side starts preparing for the next release, I get a conflict and resolve, favoring what is in the 'master'. It always is trivial and is not annoying to be any problem, though. > 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? You do not have to fork maint-0.1 branch from the tip of the master. In the earlier parts of the master branch there must be a point where everything before are for 0.1 and all things after that are not, and you fork from there. After that, queue changes that are applicable to both to the 0.1 branch and merge that to 'master' as necessary, while queueing changes not for 0.1 to 'master'. -- 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