On 10/24/2012 04:19 PM, Norbert Thiebaud wrote:
On Wed, Oct 24, 2012 at 10:10 AM, Stephan Bergmann <[email protected]> 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
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
