It makes sense to me now. +1 from me
one minor thing i would like to add is git-flow doesn’t force you to its naming
convention. You can choose any and stick to it. But, it makes sense to use the
defaults.
~Rajani
On 24-Jul-2014, at 2:52 pm, Leo Simons <lsim...@schubergphilis.com> wrote:
> On Jul 24, 2014, at 10:45 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
>> Any advice on our procedure from this, Leo?
>
> Yes, to follow all the git-flow defaults [1].
>
> * goal is for master to become stable
> * new develop which starts from master
> * create with `git flow init`
> * ‘abandon’ 4.4 / 4.4-forward
> * anything in there which is not currently
> in master gets cherry-picked into develop
> * accordingly, plan is no 4.4.1
> * if 4.4.1 becomes really necessary, create
> it by cherry-picking from develop
> * keep 4.3 to produce 4.3.1 then
> abandon it, too
>
> It is important to realize that a git-flow release/4.5 is _not_ the same as
> an old-style 4.5-forward; a lot more discipline is required.
>
> 4.4-forward contains a lot of things which are not purely bugfixes.
> 4.4-forward has additional tests, lots of changes to test suites, things that
> should go in 4.4.1 but not 4.4.0, half-merged features that were pulled from
> 4.4 but remain in 4.4-forward, bugfixes that include refactoring, etc etc. In
> a git-flow model, those things would go onto feature/ and/or support/
> branches, and from there to the develop branch, and definitiely _never_ onto
> a release branch. It was very hard to get 4.4 stable by cherry-picking from
> 4.4-forward; the discipline suggested by git-flow is _exactly_ to avoid that
> difficulty.
>
> Note git-flow defaults also include:
> * feature branches are called feature/feature-thing
> (don’t put your name in there, its meant to be
> descriptive!)
> * release branches are called release/{version}
> (not RELEASE-{version})
> * hotfixes are called hotfix/{version}-name
> and are based on & merge to master (not usually
> to a release branch, release branches are not
> hot, hotfixes are patches to previous releases,
> i.e. 4.5.1, 4.5.2, 4.5.3 will be hotfixes)
> * everyone can commit on release branches,
> everyone can merge to develop (generally you
> don’t need much merging to release branches
> since the only thing you commit there are
> bugfixes, you merge _from_ the release branch
> _to_ the develop branch), merging is _not_ a
> release manager's job (the release manager might
> review or approve bugfixes, but its the committer
> that merges)
> * no cherry-picking!
>
>
> cheers,
>
>
> Leo
>
> [1] unfortunately, the reason I did this analysis work yesterday was to try
> and find a way to start from 4.4 and go forward from there, first merging in
> 4.4-forward and then master, but I don’t see that happening
>
>> On Thu, Jul 24, 2014 at 10:39 AM, Leo Simons <lsim...@schubergphilis.com>
>> wrote:
>>> branch two diff size big diff chunks
>>> branch one
>>> 4.3 4.4 11MB hyperv,netscaler,server,engine
>>> 4.4 4.4-forward 2MB tests,marvin
>>> 4.4-forward master 6MB xenapi,xen,xenserver,storage
>>> 4.4 master 8MB xenapi,tests,marvin,xen,xenserver
>>> (See below how I got the numbers.)
>>>
>>> Starting git-flow from 4.4 or 4.4-forward and then merging things in from
>>> master means processing hundreds of thousands of lines of diff. Of those
>>> lines, many many thousands of lines will probably not auto-merge due to the
>>> cherry-pick approach. A rebase between any of these branches is not
>>> feasible; git cannot un-pick what happened so it cannot offer much
>>> assistance.
>
