Hi helpful git users! I have a pattern for work (which may be flawed--feel free to jab it) that leads me to a difficult maintenance story: Work on master..., tracked source code set to v1.0 Create branch v1.0.... tag v1.0.0 On master, increment version of library in source code to v2.0 More work on master... Cherry-pick most of the commits on master to the v1.0 branch, leaving off the commit that changed master's version number to v2.0 Tag v1.1. Work on master continues toward v2.0... Branch off v2.0... (and the pattern continues, with some commits in master getting back-ported to maintenance branches. At some point, most or all the commits on master since branching off v1.0 I want to include in the v1.1 release. When I want to include all the commits from master in the v1.0 branch I just do: git checkout v1.0 git merge master ...and life is good because gitk history makes the merge easy to see and individual commits can be easily identified as belonging to both master and v1.0. But as soon as I branch off v1.0 I want my master branch to start building as v2.0, which means the first commit after branching should never be included in the v1.0 branch. As I understand it, that rules out ever using "git merge". I believe the only option that leaves me is cherry picking individual commits, which is a maintenance pain because each commit then appears as many times as branches it belongs to, and it's difficult given just one commit to tell which branches it has been ported to. Am I doing something wrong, un-knowledgeable of how to properly do merges/cherry-picks, or is this just life as we know it? Thanks. -- Andrew Arnott -- 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
