How to keep different version numbers in different branches?

How to keep different version numbers in different branches?

[Stephen Kelly]

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.

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

[Christian MICHON]

On Mon, Apr 5, 2010 at 4:34 PM, Stephen Kelly <steveire@gmail.com> wrote:
>
> 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 !

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

[Matthieu Moy]

Stephen Kelly <steveire@gmail.com> writes:

> 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/

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

[Avery Pennarun]

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).

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).

> 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

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

[Matthieu Moy]

Avery Pennarun <apenwarr@gmail.com> writes:

> 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/

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

[Avery Pennarun]

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.

Have fun,

Avery

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

[Stephen Kelly]

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 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:
>> 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.

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

[Steven Michalske]

On Apr 6, 2010, at 3:06 AM, Stephen Kelly wrote:

> 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>

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

[Junio C Hamano]

Stephen Kelly <steveire@gmail.com> 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'.