git submodules vs translators
- From: Colin Walters <walters verbum org>
- To: desktop-devel-list gnome org
- Cc: gnome-i18n gnome org
- Subject: git submodules vs translators
- Date: Thu, 27 Jun 2013 20:01:33 -0400
The use of git submodules in GNOME is growing - there's libgd,
egg-list-box, and my own libgsystem, among others. Broadly speaking, I
think that's a good thing. They offer a reasonable set of tradeoffs
compared to "copylibs" like the old libegg model.
However, git submodules are easy to screw up unless everyone committing
to the repository is aware of how they work. This collides badly with
our current translation system where many translators commit directly to
git, resulting in commits like this one:
https://git.gnome.org/browse/gnome-control-center/commit/?id=c87483acb4cce36ffad215396dbaa4cea801c970
That commit reverted two submodules. The gnome-ostree continuous
integration system made it fairly obvious when I looked at the build
error, but two things should happen:
1) Translators: Ensure you run "git submodule update --init" after
every git pull.
2) We need some sort of sanity check in a pre-receive hook. Something
like "commits whose subjects match the regexp "Update.*translation"
are rejected if they modify submodules.
Or even stronger, one idea is that modules can opt-in to having a
file "submodule-check" which must change content for commits which
update submodules. The downside of that is it would conflict
on branch merges, but then again, the submodules would anyways.
Any other thoughts?
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]