On Mon, Apr 5, 2010 at 3:22 PM, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: > You can even make sure it _never_ happens, by making a one-commit > release branch which changes the version number for each release. This > one-commit is never merged in anything: > > 0.1 0.2 > | | > v v > --o--o--o--o--o--o--o--o---o--o--o <--- master branch > \ / > o--o--o--o--o--o--o--o--- ... <--- maintainance branch > \ \ > o <- 0.1.1 o <- 0.1.2 > > Here, the maintainance branch never changes the version number in > README & friends. This works too. In fact, I even do it on one of my projects. However, I find it a little annoying, because then I don't know which version to tag: the pre-number-changed version, or the post-number-changed version. The latter sounds like the obvious answer, but if I do that, then "git describe" never says anything useful on my master branch. But if I do the former instead, then the tag doesn't accurately reflect the version I *actually* released. I've never found an adequate solution to this problem, other than not including the version number in the repo at all. 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