[TYPO3-v4] Git submodules or not?

[Ernesto Baschny [cron IT]]

Hi,

thanks for the valuable feedback. So it seems that most developers are
fine with the submodules, considering these conditions:

1) no new submodules are created on existing branches

2) you get no trouble if you use the "multiple branch setup" (one
directory per release), so you don't switch to different release
branches within one working copy

So considering this, remains only:

- document better the multiple branch setup, and add a hint or two for
Windows users (so that they simply clone the source multiple times,
instead of doing the symlinking stuff, as disk-space is cheap anyway).

- I would also like to see a more detailed view of "what has changed" in
the submodules in our main ChangeLog. This is nothing new, we have had
this problem with SVN too: We have for example "dc3c35e [TASK] Raise
submodule pointer" in the 4.5 ChangeLog which doesn't even say which
submodule (it's dbal) and also not what was changed of fixed by this
"raising". Maybe Olly could include this information in the ChangeLog
generation script? In this case, it would be:

93b6a39 [BUGFIX] Incorrect handler detected with DELETE, INSERT and UPDATE

Other than that, I close my RFC about the submodules issue. Thanks!

Cheers,
Ernesto

Ernesto Baschny [cron IT] schrieb am 22.08.2011 09:45:
> Hi,
> 
> I'd like to re-open a discussion which we hold some months back, where
> the Core Team decided to go for "submodules" when including external
> team projects into the core (i.e Workspaces, DBAL, Linkvalidator, etc).
> 
> While it has proven to work, and Olly has made a great job in keeping
> all things linked together (thanks!!!) I rather feel that the submodules
> are the only one big pain in the a** for all kinds of troubles the
> developers are having with our GIT repository: Be it when switching
> branches, even when switching their local branches, or when suddenly
> having to cope with "untracked modified files", etc.
> 
> Before introducing them, Olly made a list of advantages / disadvantages
> for the two methods we have at our disposal:
> 
> 1) Subtree merge
>  - there will be one big commit to the Core repository containing
>    all changes since the last merge
>  - development currently happens in local extensions in typo3conf/ext/
>  + by just checking out the Core repository one has everything she
>    needs (not further requirement of initializing something)
> 
> 2) Submodules
>  - additional initializations and updates to the submodules are required
>    (if not doing this, the Core source will be incomplete)
>  - additional documentation is required for init, update, commit hooks
>  + makes the life for developers a bit easier since the just work with
>    one source directory and git takes care to put the things to the
>    accordant repositories and branches there
> 
> The bottom line was that Git is "for developers" and they should be able
> to handle the additional overhead that Submodules might cause.
> 
> After three months of experience gained, I tend to rethink about it, and
> consider moving back to Subtree merging after the release of 4.6.0 (and
> branching 4.6) which would avoid most of the trouble for the "regular
> developer" (which is not even interested in developing in one of the
> external projects), but put a bit more overhead for the project leaders
> (or maybe on the Release Managers / Team Leader) - at least while we
> cannot automate the merges into the core.
> 
> What do you think?
> 
> Cheers,
> Ernesto