[TYPO3-v4] Core projects merge via subtree merge?

[Ernesto Baschny [cron IT]]

Tolleiv.Nietsch schrieb am 07.03.2011 16:09:

>> So maybe we should do it for bug fixes (older branches) and only squash
>> commits into one if there was really a huge new feature being
>> implemented which has to "enter the core" (in which case one huge
>> squashed commit should be fine).
>>
>> What do you think?

> Well I think we can't do both at the same time ;)

Why not? Technically not possible you mean? Reading the git pro
walkthrough for this feature [1] it looks like you can do it differently
on different branches.

You checkout "workspaces_master", do a git pull, go back to typo3's
"master" (git checkout master) and then do a git merge --squash for the
workspaces subtree (for example). Then you have in the core the whole
history of changes done by the upstream external project.

And then for 4-5 you checkout workspaces_4-5 and do the same as above,
but instead you do a git merge without --squash at the end.

Haven't tested it, but.. wouldn't it work?

[1] http://progit.org/book/ch6-7.html

> Of course someone
> could go through the history and do this by hand before the merge, but
> he might still "loose" some commits which would cause lot's of
> confusion. Besides that we still end up doing double reviews for all
> bugfix commits.
> 
> For the next 4.5.x releases I tend to squash everything into a single
> commit just to avoid confusion and also because this is how we handled
> it in the past with SVN.

Which is what I disliked in the past. One huge commit with all changes
between 4.5.1 and 4.5.2, no easy way to figure out *what* did break in
between for example. Also no easy way automatically generate a complete
changelog of the whole core, including all external extensions, which is
an useful asset for users deciding what has changed between one and the
next package.

> For 4.6.x releases I'd personally prefer to having something which does
> this automatically without squashing. This could happen on a regular
> occasion (sunday night) or we could merge the subproject into the Core
> once the subproject get's a new tag (which ensures that the teams have
> the control).

I think this can be done for 4.5 and older branches too (the automatic
merge, without squashing), even "daily" would be possible. So that the
release process is simple "take the current state" and release. Also
makes our "daily snapshots" really complete with all sub-projects
included in their latests state, while still allowing the external teams
to do their "own work".

In this case, "experimental stuff" and "huge new features" should be
done in experimental branches which are not merged into our core
automatically. The teams can then add their new feature in one squashed
merge after it has been reach a state where it deserves to be in the core.

If we do it like this, we can do a regular merges without squashing for
all branches! I love it! What do you think?

Cheers,
Ernesto