[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
sbergman at redhat.com
Wed Oct 24 09:59:09 PDT 2012
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
"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.
More information about the LibreOffice