[Kde-scm-interest] Package splitting

[Pau Garcia i Quiles]

Hello,

Let me express my opinion here: git submodules are a piece of shit.
There are no convenient to work with. They are not svn externals. They
do not update to the latest version. If you are a developer (i. e.
modifying and committing code), you need to know a directory is a
submodule and remember to commit/push/pull at the right place, in the
right order. Git submodules are so bad Google needed to hack 'repo'
(others have hacked they own solutions, too, all of them similar to
repo).

What I said is pretty much confirmed by a recent thread in the git mailing list:
http://thread.gmane.org/gmane.comp.version-control.git/136029

What we really need here is someone to step forward and develop
something more like svn externals (which, with all the flaws of svn,
work great). For starters, I'd like to see two features:
- automagically clone submodules when I clone the repository
containing submodules (i. e. no need for git submodule init)
- be able to stick to the tip (HEAD, instead of a certain revision
which I have to manually update)
- submodules should be read-only (IIRC this is doable now, by using
the read-only URL for the submodule repository) unless the
"commit/push/pull in the right order" issue is resolved by this new
"git externals" command

With those two features, I'd say the problem we have here would be
much simpler to solve:
- Splitting would be possible and dependencies would be mostly
automagically resolved by CMake
- Splitting would mean a bit of CMake code duplication. So what.
- When I clone, say, okular.git, it would automagically clone the
'kdegraphics-cmake.git' directory from kdegraphics and it would just
work


2010/1/28 Chani <chanika at gmail.com>:
> On January 27, 2010 01:45:09 Thiago Macieira wrote:
>> Em Quarta-feira 27 Janeiro 2010, às 09:35:21, Chani escreveu:
>> > > You don't want to track. The point is to remember, when you go back in
>> > > time, which revision is known to work. More importantly, when you tag,
>> > > you know exactly what you released.
>> >
>> > what's the downside of having a repository composed of thousands of
>> > "update subrepo foo" commits? we're past a million svn commits now,
>> > that's a lot of committing - but now that I think about it I'm having
>> > trouble coming up wth an actual problem with that. apart from the
>> > potential cpu and network load for the update bot, which could be tiny
>> > for all I know.
>>
>> You don't update the supermodule unless you want to say something.
>>
>> For example, when we're about to tag, tag all repositories, then the
>> supermodule.
>>
>> Other than that, there's no need to change the supermodule at all.
>>
>
> what? but then when someone downloads the kdegames supermodule, thinking that
> they're getting all hte latest kdegames code, they'd actually get... what? the
> code from the last tag, possibly weeks ago?
>
> and then to get the actual latest kdegames code you'd have to do some git
> command in each individual game repo?
>
> then we're back at square one.
>
> the problem I was trying to solve here was the "I want all of games and edu
> without running over a dozen commands", not just the question of "what counts
> as part of kdegames?"
>
> in order to do that with submdules, *something* has to be continually updating
> the supermodule to point to the latest revisions of everything.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)