{"thread":{"id":"23337","subject":"How to keep different version numbers in different branches?","startedAt":"2010-04-05T14:34:07Z","lastAt":"2010-04-06T11:29:16Z","messageCount":9,"participants":["Stephen Kelly","Christian MICHON","Matthieu Moy","Avery Pennarun","Junio C Hamano","Steven Michalske"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"138595","messageId":"hpcscv$umg$3@dough.gmane.org","threadId":"23337","inReplyTo":null,"subject":"How to keep different version numbers in different branches?","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2010-04-05T14:34:07Z","receivedAt":"2010-04-05T14:34:07Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"\nHi,\n\nMy project uses git and so far has only one branch, 'master'.\n\nhttp://gitorious.org/grantlee/grantlee\n\nI want to make a 0.1 release, so that would mean creating a 0.1 branch and \nupdating files contained in the branch such as the README file and the CMake \nfiles and the api documentation to report version 0.1.0, and creating the \n0.1.0 tag. The next tag on that branch would be 0.1.1 etc. Simultaneously, \nthe version number in those files is changes to 0.2.0 in the master branch.\n\nHowever, now I have changes in my maintenance branch (0.1) which should not \nbe merged into master (that is, the commits which change the version \nnumber). \n\nHow are you supposed to handle that with git? Simply merge and resolve the \nconflict on master by keeping its version number? Am I missing some other \nway of doing it here?\n\nAdditionally, I have some stuff currently in master that should not be in \nthe 0.1 release, but should be in the 0.2 release. If I branch and then \nremove those files from the 0.1 branch, a merge will then remove them from \nmaster too? How do I keep them on master but delete them on 0.1 and still be \nable to merge from 0.1 into master?\n\nThe only option I can think of are to do the merge, then revert the commit \nsha on master that does the delete.\n\nIs that the recommended way of doing this? I have read the git workflows \npage, but it doesn't seem to cover either of these scenarios.\n\nhttp://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html\n\nThanks,\n\nSteve.\n"},{"id":"138604","messageId":"i2j46d6db661004051050rfb6aa9d0i3a9e20a348e5a110@mail.gmail.com","threadId":"23337","inReplyTo":"hpcscv$umg$3@dough.gmane.org","subject":"Re: How to keep different version numbers in different branches?","fromName":"Christian MICHON","fromEmail":"christian.michon@gmail.com","sentAt":"2010-04-05T17:50:01Z","receivedAt":"2010-04-05T17:50:01Z","isPatch":false,"sender":{"key":"christian.michon@gmail.com","avatar":"https://gravatar.com/avatar/8a7c327b21187fbcab5c27640a49450eec72e0355dc292501197f27a5a744ec4?d=mp&s=160"},"body":"On Mon, Apr 5, 2010 at 4:34 PM, Stephen Kelly wrote:\n>\n> Hi,\n>\n> My project uses git and so far has only one branch, 'master'.\n>\n> http://gitorious.org/grantlee/grantlee\n>\n> I want to make a 0.1 release, so that would mean creating a 0.1 branch and\n> updating files contained in the branch such as the README file and the CMake\n> files and the api documentation to report version 0.1.0, and creating the\n> 0.1.0 tag. The next tag on that branch would be 0.1.1 etc. Simultaneously,\n> the version number in those files is changes to 0.2.0 in the master branch.\n>\n> However, now I have changes in my maintenance branch (0.1) which should not\n> be merged into master (that is, the commits which change the version\n> number).\n>\n> How are you supposed to handle that with git? Simply merge and resolve the\n> conflict on master by keeping its version number? Am I missing some other\n> way of doing it here?\n>\n> Additionally, I have some stuff currently in master that should not be in\n> the 0.1 release, but should be in the 0.2 release. If I branch and then\n> remove those files from the 0.1 branch, a merge will then remove them from\n> master too? How do I keep them on master but delete them on 0.1 and still be\n> able to merge from 0.1 into master?\n>\n> The only option I can think of are to do the merge, then revert the commit\n> sha on master that does the delete.\n>\n> Is that the recommended way of doing this? I have read the git workflows\n> page, but it doesn't seem to cover either of these scenarios.\n>\n> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html\n>\n> Thanks,\n>\n> Steve.\n>\n\nSteve,\n\nyou might want to have a look at this: http://nvie.com/git-model\n\nRgds,\n\n-- \nChristian\n--\nhttp://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !\n"},{"id":"138608","messageId":"vpqhbnprcj0.fsf@bauges.imag.fr","threadId":"23337","inReplyTo":"hpcscv$umg$3@dough.gmane.org","subject":"Re: How to keep different version numbers in different branches?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-04-05T18:15:47Z","receivedAt":"2010-04-05T18:15:47Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Stephen Kelly writes:\n\n> Hi,\n>\n> My project uses git and so far has only one branch, 'master'.\n>\n> http://gitorious.org/grantlee/grantlee\n>\n> I want to make a 0.1 release, so that would mean creating a 0.1 branch and \n> updating files contained in the branch such as the README file and the CMake \n> files and the api documentation to report version 0.1.0, and creating the \n> 0.1.0 tag. The next tag on that branch would be 0.1.1 etc. Simultaneously, \n> the version number in those files is changes to 0.2.0 in the master branch.\n\nYou can have this number generated by your build script instead of\nhaving to commit it. See what git does, for example. The command \"git\ndescribe\" should help.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"138654","messageId":"y2i32541b131004051151v8f4b8774q360c04ecdb046778@mail.gmail.com","threadId":"23337","inReplyTo":"hpcscv$umg$3@dough.gmane.org","subject":"Re: How to keep different version numbers in different branches?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-04-05T18:51:35Z","receivedAt":"2010-04-05T18:51:35Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Apr 5, 2010 at 10:34 AM, Stephen Kelly wrote:\n> I want to make a 0.1 release, so that would mean creating a 0.1 branch and\n> updating files contained in the branch such as the README file and the CMake\n> files and the api documentation to report version 0.1.0, and creating the\n> 0.1.0 tag. The next tag on that branch would be 0.1.1 etc. Simultaneously,\n> the version number in those files is changes to 0.2.0 in the master branch.\n>\n> However, now I have changes in my maintenance branch (0.1) which should not\n> be merged into master (that is, the commits which change the version\n> number).\n>\n> How are you supposed to handle that with git? Simply merge and resolve the\n> conflict on master by keeping its version number? Am I missing some other\n> way of doing it here?\n\nI've used that method. it works fine, and the conflicts are only\nwhenever the maintenance branch version number changes, which is very\nrare (and easy to see).\n\nAs someone else suggested, doing it the way git.git does (using\nessentially 'git describe HEAD') is another method, though you then\ndepend on having your source code built from the git repo unless you\ndo even fancier stuff (like git.git does).\n\n> Additionally, I have some stuff currently in master that should not be in\n> the 0.1 release, but should be in the 0.2 release. If I branch and then\n> remove those files from the 0.1 branch, a merge will then remove them from\n> master too? How do I keep them on master but delete them on 0.1 and still be\n> able to merge from 0.1 into master?\n>\n> The only option I can think of are to do the merge, then revert the commit\n> sha on master that does the delete.\n\nThat method will work fine. You could also squash the revert commit\ninto your merge commit if you want, so that you never have a commit on\nmaster that has the unwanted changes. (That'll help when bisecting.)\nTo do that, just revert using \"git revert -n\", then commit it with\n\"git commit -a --amend\".\n\nHave fun,\n\nAvery\n"},{"id":"138660","messageId":"7vwrwlogiz.fsf@alter.siamese.dyndns.org","threadId":"23337","inReplyTo":"hpcscv$umg$3@dough.gmane.org","subject":"Re: How to keep different version numbers in different branches?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-05T19:17:40Z","receivedAt":"2010-04-05T19:17:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephen Kelly writes:\n\n> However, now I have changes in my maintenance branch (0.1) which should not \n> be merged into master (that is, the commits which change the version \n> number). \n>\n> How are you supposed to handle that with git? Simply merge and resolve the \n> conflict on master by keeping its version number? Am I missing some other \n> way of doing it here?\n\nOthers already have commented on this. The basic idea is avoid hardcoded\nversions in the tracked contents.\n\nHaving said that, I do have a few instances of something similar in\ngit.git itself: GIT-VERSION-GEN script and the RelNotes symlink that\npoints at Documentation/RelNotes-$v.txt file. Every time I merge from\nmaint to master after either side starts preparing for the next release, I\nget a conflict and resolve, favoring what is in the 'master'. It always\nis trivial and is not annoying to be any problem, though.\n\n> Additionally, I have some stuff currently in master that should not be in \n> the 0.1 release, but should be in the 0.2 release. If I branch and then \n> remove those files from the 0.1 branch, a merge will then remove them from \n> master too? How do I keep them on master but delete them on 0.1 and still be \n> able to merge from 0.1 into master?\n\nYou do not have to fork maint-0.1 branch from the tip of the master. In\nthe earlier parts of the master branch there must be a point where\neverything before are for 0.1 and all things after that are not, and you\nfork from there. After that, queue changes that are applicable to both to\nthe 0.1 branch and merge that to 'master' as necessary, while queueing\nchanges not for 0.1 to 'master'.\n"},{"id":"138661","messageId":"vpqd3ydr9g6.fsf@bauges.imag.fr","threadId":"23337","inReplyTo":"y2i32541b131004051151v8f4b8774q360c04ecdb046778@mail.gmail.com","subject":"Re: How to keep different version numbers in different branches?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-04-05T19:22:17Z","receivedAt":"2010-04-05T19:22:17Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Avery Pennarun writes:\n\n> On Mon, Apr 5, 2010 at 10:34 AM, Stephen Kelly wrote:\n>> I want to make a 0.1 release, so that would mean creating a 0.1 branch and\n>> updating files contained in the branch such as the README file and the CMake\n>> files and the api documentation to report version 0.1.0, and creating the\n>> 0.1.0 tag. The next tag on that branch would be 0.1.1 etc. Simultaneously,\n>> the version number in those files is changes to 0.2.0 in the master branch.\n>>\n>> However, now I have changes in my maintenance branch (0.1) which should not\n>> be merged into master (that is, the commits which change the version\n>> number).\n>>\n>> How are you supposed to handle that with git? Simply merge and resolve the\n>> conflict on master by keeping its version number? Am I missing some other\n>> way of doing it here?\n>\n> I've used that method. it works fine, and the conflicts are only\n> whenever the maintenance branch version number changes, which is very\n> rare (and easy to see).\n\nYou can even make sure it _never_ happens, by making a one-commit\nrelease branch which changes the version number for each release. This\none-commit is never merged in anything:\n\n 0.1 0.2\n | |\n v v\n--o--o--o--o--o--o--o--o---o--o--o <--- master branch\n \\ /\n o--o--o--o--o--o--o--o--- ... <--- maintainance branch\n \\ \\\n o <- 0.1.1 o <- 0.1.2\n\nHere, the maintainance branch never changes the version number in\nREADME & friends.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"138664","messageId":"n2x32541b131004051236m3a800c57k41536729ae3f192@mail.gmail.com","threadId":"23337","inReplyTo":"vpqd3ydr9g6.fsf@bauges.imag.fr","subject":"Re: How to keep different version numbers in different branches?","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-04-05T19:36:51Z","receivedAt":"2010-04-05T19:36:51Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Apr 5, 2010 at 3:22 PM, Matthieu Moy\n wrote:\n> You can even make sure it _never_ happens, by making a one-commit\n> release branch which changes the version number for each release. This\n> one-commit is never merged in anything:\n>\n>  0.1                         0.2\n>  |                           |\n>  v                           v\n> --o--o--o--o--o--o--o--o---o--o--o <--- master branch\n>   \\                      /\n>    o--o--o--o--o--o--o--o--- ...  <--- maintainance branch\n>           \\              \\\n>            o <- 0.1.1     o <- 0.1.2\n>\n> Here, the maintainance branch never changes the version number in\n> README & friends.\n\nThis works too. In fact, I even do it on one of my projects.\nHowever, I find it a little annoying, because then I don't know which\nversion to tag: the pre-number-changed version, or the\npost-number-changed version.\n\nThe latter sounds like the obvious answer, but if I do that, then \"git\ndescribe\" never says anything useful on my master branch. But if I do\nthe former instead, then the tag doesn't accurately reflect the\nversion I *actually* released.\n\nI've never found an adequate solution to this problem, other than not\nincluding the version number in the repo at all.\n\nHave fun,\n\nAvery\n"},{"id":"138728","messageId":"hpetj1$6af$1@dough.gmane.org","threadId":"23337","inReplyTo":"n2x32541b131004051236m3a800c57k41536729ae3f192@mail.gmail.com","subject":"Re: How to keep different version numbers in different branches?","fromName":"Stephen Kelly","fromEmail":"steveire@gmail.com","sentAt":"2010-04-06T10:06:42Z","receivedAt":"2010-04-06T10:06:42Z","isPatch":false,"sender":{"key":"steveire@gmail.com","avatar":null},"body":"Avery Pennarun wrote:\n\n> On Mon, Apr 5, 2010 at 3:22 PM, Matthieu Moy\n> wrote:\n>> You can even make sure it _never_ happens, by making a one-commit\n>> release branch which changes the version number for each release. This\n>> one-commit is never merged in anything:\n>>\n>> 0.1 0.2\n>> | |\n>> v v\n>> --o--o--o--o--o--o--o--o---o--o--o <--- master branch\n>> \\ /\n>> o--o--o--o--o--o--o--o--- ... <--- maintainance branch\n>> \\ \\\n>> o <- 0.1.1 o <- 0.1.2\n>>\n>> Here, the maintainance branch never changes the version number in\n>> README & friends.\n> \n> This works too. In fact, I even do it on one of my projects.\n> However, I find it a little annoying, because then I don't know which\n> version to tag: the pre-number-changed version, or the\n> post-number-changed version.\n> \n> The latter sounds like the obvious answer, but if I do that, then \"git\n> describe\" never says anything useful on my master branch. But if I do\n> the former instead, then the tag doesn't accurately reflect the\n> version I *actually* released.\n> \n> I've never found an adequate solution to this problem, other than not\n> including the version number in the repo at all.\n\nHi all, \n\nThanks for the pointers. I considered the above solution too, but \ndisregarded it for the same reason.\n\nI also considered the git describe solution, but disregarded it because in \nCMake I need to know each component of the version separately \n(Grantlee_VERSION_MAJOR, Grantlee_VERSION_MINOR and Grantlee_VERSION_PATCH). \nI could split it on '.', but I think the better solution is to just put the \nversion into the CMake files and deal with the conflict in that one place as \nit comes up. I can always switch in the future anyway if using describe \nmakes more sense.\n\n> you might want to have a look at this: http://nvie.com/git-model\n\nYes, that is an interesting read, but he doesn't cover this issue. In fact, \nhe references a fictional script which updates the version number in the \ntracked files.\n\nJunio C Hamano wrote:\n>> Additionally, I have some stuff currently in master that should not be in\n>> the 0.1 release, but should be in the 0.2 release. If I branch and then\n>> remove those files from the 0.1 branch, a merge will then remove them\n>> from master too? How do I keep them on master but delete them on 0.1 and\n>> still be able to merge from 0.1 into master?\n> \n> You do not have to fork maint-0.1 branch from the tip of the master. In\n> the earlier parts of the master branch there must be a point where\n> everything before are for 0.1 and all things after that are not, and you\n> fork from there. After that, queue changes that are applicable to both to\n> the 0.1 branch and merge that to 'master' as necessary, while queueing\n> changes not for 0.1 to 'master'.\n> \n\nThere might be such a point, yes, but there are also likely commits which \ntouch files which should be included and files which should not, so I'd \nprobably end up rebasing ancient history of master and or creating a big \nmess.\n\nI think for this situation the best solution is indeed the merge_revert \ncommit.\n\nThanks for the responses.\n\nAll the best,\n\nSteve.\n"},{"id":"138738","messageId":"6C464226-8D13-4FB1-9017-C410011247D3@gmail.com","threadId":"23337","inReplyTo":"hpetj1$6af$1@dough.gmane.org","subject":"Re: How to keep different version numbers in different branches?","fromName":"Steven Michalske","fromEmail":"smichalske@gmail.com","sentAt":"2010-04-06T11:29:16Z","receivedAt":"2010-04-06T11:29:16Z","isPatch":false,"sender":{"key":"smichalske@gmail.com","avatar":"https://gravatar.com/avatar/721f27456adc9ac84f3bb235f021a70015abb9e09222ae8622fc5579c6a203c1?d=mp&s=160"},"body":"\nOn Apr 6, 2010, at 3:06 AM, Stephen Kelly wrote:\n\n> Avery Pennarun wrote:\n>\n>> On Mon, Apr 5, 2010 at 3:22 PM, Matthieu Moy\n>> wrote:\n>>> You can even make sure it _never_ happens, by making a one-commit\n>>> release branch which changes the version number for each release. \n>>> This\n>>> one-commit is never merged in anything:\n>>>\n>>> 0.1 0.2\n>>> | |\n>>> v v\n>>> --o--o--o--o--o--o--o--o---o--o--o <--- master branch\n>>> \\ /\n>>> o--o--o--o--o--o--o--o--- ... <--- maintainance branch\n>>> \\ \\\n>>> o <- 0.1.1 o <- 0.1.2\n>>>\n>>> Here, the maintainance branch never changes the version number in\n>>> README & friends.\n>>\n>> This works too. In fact, I even do it on one of my projects.\n>> However, I find it a little annoying, because then I don't know which\n>> version to tag: the pre-number-changed version, or the\n>> post-number-changed version.\n>>\n>> The latter sounds like the obvious answer, but if I do that, then \n>> \"git\n>> describe\" never says anything useful on my master branch. But if I \n>> do\n>> the former instead, then the tag doesn't accurately reflect the\n>> version I *actually* released.\n>>\n>> I've never found an adequate solution to this problem, other than not\n>> including the version number in the repo at all.\n>\n> Hi all,\n>\n> Thanks for the pointers. I considered the above solution too, but\n> disregarded it for the same reason.\n>\n> I also considered the git describe solution, but disregarded it \n> because in\n> CMake I need to know each component of the version separately\n> (Grantlee_VERSION_MAJOR, Grantlee_VERSION_MINOR and \n> Grantlee_VERSION_PATCH).\n> I could split it on '.', but I think the better solution is to just \n> put the\n> version into the CMake files and deal with the conflict in that one \n> place as\n> it comes up. I can always switch in the future anyway if using \n> describe\n> makes more sense.\n>\n\nYou might want to look into a filter that edits the cmake file.\n\nsmudge in the version information, and clean it out.\n\nSee keyword expansion \n"}]}