threads / discuss / 23337

How to keep different version numbers in different branches?

Subject: How to keep different version numbers in different branches?

## tl;dr

9 messages between Apr 5, 2010 and Apr 6, 2010.

replies: 8people: 6as markdown or json

Stephen Kelly· Apr 5, 2010, 14:34 UTC · lore
Hi,
My project uses git and so far has only one branch, 'master'.
http://gitorious.org/grantlee/grantlee

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?

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.

Is that the recommended way of doing this? I have read the git workflows page, but it doesn't seem to cover either of these scenarios.

http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
Thanks,
Steve.
Christian MICHON· Apr 5, 2010, 17:50 UTC · re: Stephen Kelly · lore

Re: How to keep different version numbers in different branches?

On Mon, Apr 5, 2010 at 4:34 PM, Stephen Kelly <steveire@gmail.com> wrote:
Show 39 quoted lines
>
> Hi,
>
> My project uses git and so far has only one branch, 'master'.
>
> http://gitorious.org/grantlee/grantlee
>
> 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?
>
> 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.
>
> Is that the recommended way of doing this? I have read the git workflows
> page, but it doesn't seem to cover either of these scenarios.
>
> http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>
> Thanks,
>
> Steve.
>
Steve,
you might want to have a look at this: http://nvie.com/git-model
Rgds,
-- 
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
Matthieu Moy· Apr 5, 2010, 18:15 UTC · re: Stephen Kelly · lore

Re: How to keep different version numbers in different branches?

Stephen Kelly <steveire@gmail.com> writes:
Show 11 quoted lines
> Hi,
>
> My project uses git and so far has only one branch, 'master'.
>
> http://gitorious.org/grantlee/grantlee
>
> 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.

You can have this number generated by your build script instead of having to commit it. See what git does, for example. The command "git describe" should help.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Avery Pennarun· Apr 5, 2010, 18:51 UTC · re: Stephen Kelly · lore

Re: How to keep different version numbers in different branches?

On Mon, Apr 5, 2010 at 10:34 AM, Stephen Kelly <steveire@gmail.com> wrote:
Show 13 quoted lines
> 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).

Show 8 quoted lines
> 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
Matthieu Moy· Apr 5, 2010, 19:22 UTC · re: Avery Pennarun · lore

Re: How to keep different version numbers in different branches?

Avery Pennarun <apenwarr@gmail.com> writes:
Show 18 quoted lines
> On Mon, Apr 5, 2010 at 10:34 AM, Stephen Kelly <steveire@gmail.com> 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).

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.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Avery Pennarun· Apr 5, 2010, 19:36 UTC · re: Matthieu Moy · lore

Re: How to keep different version numbers in different branches?

On Mon, Apr 5, 2010 at 3:22 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 15 quoted lines
> 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
Stephen Kelly· Apr 6, 2010, 10:06 UTC · re: Avery Pennarun · lore

Re: How to keep different version numbers in different branches?

Avery Pennarun wrote:
Show 30 quoted lines
> On Mon, Apr 5, 2010 at 3:22 PM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> 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.
Hi all,

Thanks for the pointers. I considered the above solution too, but disregarded it for the same reason.

I also considered the git describe solution, but disregarded it because in CMake I need to know each component of the version separately (Grantlee_VERSION_MAJOR, Grantlee_VERSION_MINOR and Grantlee_VERSION_PATCH). I could split it on '.', but I think the better solution is to just put the version into the CMake files and deal with the conflict in that one place as it comes up. I can always switch in the future anyway if using describe makes more sense.

> you might want to have a look at this: http://nvie.com/git-model

Yes, that is an interesting read, but he doesn't cover this issue. In fact, he references a fictional script which updates the version number in the tracked files.

Junio C Hamano wrote:
Show 13 quoted lines
>> 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'.
>

There might be such a point, yes, but there are also likely commits which touch files which should be included and files which should not, so I'd probably end up rebasing ancient history of master and or creating a big mess.

I think for this situation the best solution is indeed the merge_revert commit.

Thanks for the responses.
All the best,
Steve.
Steven Michalske· Apr 6, 2010, 11:29 UTC · re: Stephen Kelly · lore

Re: How to keep different version numbers in different branches?

On Apr 6, 2010, at 3:06 AM, Stephen Kelly wrote:
Show 54 quoted lines
> Avery Pennarun wrote:
>
>> On Mon, Apr 5, 2010 at 3:22 PM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> 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.
>
> Hi all,
>
> Thanks for the pointers. I considered the above solution too, but
> disregarded it for the same reason.
>
> I also considered the git describe solution, but disregarded it  
> because in
> CMake I need to know each component of the version separately
> (Grantlee_VERSION_MAJOR, Grantlee_VERSION_MINOR and  
> Grantlee_VERSION_PATCH).
> I could split it on '.', but I think the better solution is to just  
> put the
> version into the CMake files and deal with the conflict in that one  
> place as
> it comes up. I can always switch in the future anyway if using  
> describe
> makes more sense.
>
You might want to look into a filter that edits the cmake file.
smudge in the version information, and clean it out.
See  keyword expansion <http://progit.org/book/ch7-2.html>
Junio C Hamano· Apr 5, 2010, 19:17 UTC · re: Stephen Kelly · lore

Re: How to keep different version numbers in different branches?

Stephen Kelly <steveire@gmail.com> writes:
Show 7 quoted lines
> 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.

Show 5 quoted lines
> 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'.

← back to recent threads