Question: next, master and pu branches

Question: next, master and pu branches

[Alexander Litvinov]

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 ?

Question: next, master and pu branches

[Alexander Litvinov]

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 ?

Re: Question: next, master and pu branches

[Shawn O. Pearce]

Alexander Litvinov <litvinov2004@gmail.com> wrote:
> Can somebody explain the meaning of next and pu branches

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.

>and some documenation 
> about using topic branches.

What about Documentation/howto/using-topic-branches.txt ?
 
> 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 ?

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.

-- 
Shawn.

Re: Question: next, master and pu branches

[Junio C Hamano]

Alexander Litvinov <litvinov2004@gmail.com> writes:

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

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

Re: Question: next, master and pu branches

[Alexander Litvinov]

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

Re: Question: next, master and pu branches

[Alexander Litvinov]

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

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 ?

Re: Question: next, master and pu branches

[Shawn O. Pearce]

Alexander Litvinov <litvinov2004@gmail.com> wrote:
> > 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.
> 
> 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 ?

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

-- 
Shawn.