Question: next, master and pu branches

Hello,

Can somebody explain the meaning of next and pu branches and some documenation about using topic branches.

My development model use two branches now: stable release and develment branch. All changes in the stable release branch are bug-fix only changes. All (or most) of them must go to development release. Now I do this using cherry-pick but it is not easy to track what was merged especialy when merge pruduce confic resloved by hands. Stable branch live long life, much more than 100 commits.

It seems topic branches can help me here, but reading Documentation under git sources teach to make topic branch from the branch point and then merge it to both branches. This can work while stable branch has short life and was not heavily rewritten.

If there any technique that can help me ?

Alexander Litvinov <litvinov2004@gmail.com> wrote:

Within git.git:

  maint: Current stable release.  Receives bug fixes for the
  current release.

  master: Stable development tip.  The tip of this branch will be
  used to create the next stable release.

  next: Topics which are pretty stable and are likely to be merged
  into master soon are merged here first, to make them visible to
  a wider community and get more testing.

  pu: aka "Proposed Updates".  Junio publishes a number of branches
  here and continously rebases this branch.  Topics here may make
  it into next (and then later master), or may not and just be
  dropped forever.

What about Documentation/howto/using-topic-branches.txt ?
 

The easiest way to do this is to create a new topic branch from the merge base of the two branches (see git-merge-base's docs for details). Make the fix on this branch, test it, then merge it into your development branch.

If additional changes are needed, go back to the topic branch, fix it there, then remerge the topic to your development branch.

When the topic is finally ready, merge it to your stable branch.

This is what the documentation suggests, because it works, and works well. This is how Junio manages `next` (which is the same as your development branch) and `master` (which is about the same as your stable branch).

You can let git-rerere help you to manage conflicts which might reoccur during merges. If you create the .git/rr-cache directory then git-commit and git-merge will automatically use git-rerere to help you.

If you are cherry-picking stuff back and forth this gets really hard, as you point out. The tools don't help you very well here, as there isn't enough data to figure out what is where. You can try using git-cherry to tell you which commits are in both branches, but it has limited usefulness if the commits are making different changes.

Yes git-rerere is a black magic tool, but it works :-) Byt he way, why git-pull (or possible git-merge) does not commit the merge result after conflict was fixed by git-rerere ?

Alexander Litvinov <litvinov2004@gmail.com> wrote:

No, it doesn't. That way you can review the result of the merge first and verify its indeed correct.

Alexander Litvinov <litvinov2004@gmail.com> writes:

I think what you are looking for is how my 'maint' and 'master' branches are maintained; 'maint' corresponds to your "stable release" while 'master' corresponds to your "develment branch".

When a stable release is cut, 'maint' is forked from there.

Truly obvious corrections will be applied on top of the tip of 'maint' directly, while if there are any doubt about a proposed change I might fork a topic off of the tip of 'maint' and cook the fix for a while until I finally merge it to 'maint'. This way, 'maint' will be "bugfix only since the last release".

The tip of 'maint' will be merged into 'master', from time to time, to make sure that all fixes will be in 'master'.

When it is time for a new release to be cut, I'd make sure that the tip of 'maint' is merged into 'master' (it usually is) and then the tip of the 'master' is tagged to be released. After a release is made, I could have two maintenance branches (one that continues on top of the old codebase, another that fixes the new release). A fix that can apply to both codebases will be applied to the maintenance branch for the old release and then its tip can be pulled into the maintenance branch for the new release and then its tip can further be merged into the development branch.

At some point, the codebases for the older release and the current release become diverged enough that merging could become inpractical (the same bug may need different fix if the infrastracture has become different); you would need to bite the bullet and fix it twice (i.e. differently).

Thanks for detailed description. As a cunclusion I would like to say: all bug fixes are made in the stable branch and then stable branch will be merged to development branch. That is easy !