Question about Branches

[MiroslavR]

This may be a stupid question, but I've been wondering. Why are there some bug fixes in the openmw-31 branch that are not included in master? Is it going to be merged into master after 0.31 release or what?

[Greendogo]

(Stand back, I've got this Zini )

Yes. When we are finished with the 0.31 branch it is merged back into master.

[SquireNed]

For the curious non-coders, an article I read (i.e. I'm not a terribly prolific programmer, so don't shoot me if I'm wrong) states that this is generally considered good practice in the git community because of the fact that working on things this way allows people to be working concurrently on side projects from the common font of the master branch, then bring all their stuff back together without having to trip over each other by adding unexpected things to master.

[scrawl]

This may be a stupid question, but I've been wondering. Why are there some bug fixes in the openmw-31 branch that are not included in master?

There's not really a reason, other than laziness.
I've merged openmw-31 to master in my latest pull request to master, so it should be merged soon.

[Zini]

Currently testing that pull request. But in general I am not a fan of prematurely merging a release branch into master. This will just cause a less clean commit history, in case there are more changes to the release branch.

[scrawl]

Well, I do not agree with this logic. Keeping your branches up to date is important, especially the master branch. Less clean commit history? We're only talking about one merge commit, right?
I'm all for clean history, but there are more effective ways to improve it, like encouraging people to write better commit messages..

[Zini]

Typically the release branch will only contain release stuff (like changelog updates and version number changes) and hotfixes for problems that aren't obvious and in most cases not serious (because otherwise they would have shown up earlier). Of course, if there happen to be anything serious then merging the release branch early into master is the right thing to do.

[Chris]

IMO, all updates should go to master and any relevant commits for a release should be cherry-picked into the release branch. The only things that should get directly committed to a release branch are patches for the release branch only (e.g. temporary hacks we don't want in the main codebase, or an alternate fix for a commit that couldn't be cherry-picked), which should obviously be very rare.

[psi29a]

Rebase... (works both directions) and keeps your commit history clean.