[Libreoffice-commits] .: 5 commits - config_host.mk.in configure.ac ct2n/delzip ct2n/description-en-US.txt ct2n/Extension_ct2n.mk ct2n/Makefile ct2n/makefile.mk ct2n/Module_ct2n.mk ct2n/prj ct2n/UnpackedTarball_ct2n.mk dictionaries Makefile.top n

[Stephan Bergmann]

On 10/24/2012 04:19 PM, Norbert Thiebaud wrote:
> On Wed, Oct 24, 2012 at 10:10 AM, Stephan Bergmann <sbergman at redhat.com> wrote:
>> So when you have a core commit A and a submodule commit B that logically
>> belong together, with the above recipe the end result on the server will no
>> longer reflect that, as it "ties" B to an "artificial" core commit C
>> preceding A, instead of keeping B "tied" to A.
>
> the rational here is: pushing in submodule and forgetting a commit in
> the super module is a common anti-pattern, so gerrit automate that.
> and submodules A and B are presumably independent (the whole point of
> submodules was, in their intent to allow for such loosely connected
> section of code), so a commit in either should not be related in a
> commit to the other.

[...]

> Note: a huge majority of the commit made in submodules by dev outside
> of timar(translation) and petr(rel-eng) are actually in binfilter...
> which is going to be dropped in the not so far future....

(Just in case this got confused, what I was talking about was a relation 
between a commit in core and a commit in a submodule, not
a relation between commits in two different submodules.)

Unfortunately, our reality doesn't seem to match the expectation that 
the submodules we have allow for loose coupling of their content with 
core.  Recent 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=49a92ab374280eb340d8566d0ccc211a7fb52768> 
"commit changes in dictionries, helpcontent2, and translations" that 
accidentally caused some submodules to turn back a few commits caused 
"hell to break loose" -- in dictionaries, not binfilter.

Stephan