Re: [PROPOSAL] get rid of clone/*, use git submodules for binfilter, dictionaries and help

Hi Norbert,

On Fri, Mar 09, 2012 at 01:41:11PM -0600, Norbert Thiebaud <nthiebaud@gmail.com> wrote:
> The pros:
>
> + no more need for ./g
> + no more need for $(realpath in the build since there is no links left
> + a build point is identified by one and only one sha, which is
> imperative to manage a build-farm ( gerrit+jenkins and the ability to
> test-build every patches)

Nice!

> translations will be moved to ./translations but will not be made a
> submodules due to its prohibitive size.

Is this really an issue? Right now only the relevant repos are cloned
(e.g. by default translations is not cloned), if you do the same with
submodule init, translations could be a submodule as well. Or did I miss
something?

> The cons:
>
> - cherry picking a patch from 'before' the change to 'after' the
> change will not work if the patch impact one of these repos (due to
> the renaming). that can be mitigated with a pre-processing script to
> change the target name in the patch, since the filename pattern
> impacted is regular and easy to detect... so a simple sed should do
> the job
>
> - feature branching becomes a bit more cumbersome if you need to
> branch one of the submodule. it boils down to remember the 'submodules
> first' rule: you need to settle submodules operations before core. So,
> for instance when merging back to master you need to merge to master
> in the submodules then commit core (still in the feature branch) to
> pick-up the merge change in the submodules and _then_ merge core.

Just to be clear: this is true for any non-core commit, not only merges.
Given how frequent non-core commits are, this can be accaptable, though.