[Kde-scm-interest] [Proposal] Package splitting with thin meta-repos

[Daniel Johnson]

Please keep responding, I want this idea stress-tested. I think that what 
you're saying is that by splitting up the modules, it will overcomplicate 
things so that it's too difficult to do manually.

I don't think this is the case, but you might be right.

My comments are inline, as always.

On Friday 29 January 2010 16:33:19 Pau Garcia i Quiles wrote:
> On Fri, Jan 29, 2010 at 7:17 PM, Daniel Johnson <computerdruid at gmail.com> 
wrote:
> > On Friday 29 January 2010 13:12:27 Pau Garcia i Quiles wrote:
> >> 2010/1/29 ComputerDruid <computerdruid at gmail.com>:
> >> > So basically I'm missing what action you need to do across the whole
> >> > of KDE that isn't a "get everything" or "update everything".
> >> 
> >> You need no new code. There's 'repo' for that case. But I'm not sure
> >> we want to go that path. I certainly dislike it.
> > 
> > I'd really like to know why you don't like it, especially since I
> > perceive it to be incredibly flexible.
> > 
> > I like the idea of using our own scripts if we were able to keep them
> > incredibly simple, because then they could hopefully be very transparent
> > (eg show the developer exactly what is going on during the clone
> > operation).
> 
> Well, I don't.
> 
> I'd like to be able to clone the repositories using just git, no need
> for helper scripts. If I want a helper, I already have kdesvn-build
> (or that other tool Michale Jansen is developing, can't remember the
> name). See my point? Either you use the tools alone, or you go with
> full-featured tools like kdesvn-build. What you are proposing is
> essentially a kdesvn-build-lite. There would be nothing wrong with
> your proposal if we didn't already have two tools for that
> (kdesvn-build and MJansen's). But we do.

What I AM proposing is like a kdesvnbuild-lite. (Except without the svn. Or 
the build. Mostly just the lite.) But I disagree that we do have two tools 
that fulfill the task of a "kdesvn-build-lite". Kdesvnbuild is great, but 
sometimes you just want to get closer to the underlying software. This 
SHOULDN'T be a piece of real software, just a few helper scripts to make mass 
operations easier.

If you want to clone them manually, then I'm saying that under this system, 
you could do it rather easily, just run down the list of submodules provided 
and clone them one by one. Or write a script to go through the list and...oh, 
wait.
> >> As I said before, IMHO the need for something like 'svn externals'
> >> should be fulfilled in git (i. e. adding a new subcommand to the git
> >> suite, not creating our own command). I already pointed to a thread
> >> where this was being discussed. Submodules only work for a very
> >> specific case.
> > 
> > But these type of external modules seems restrictive, since you're
> > basically forced to get everything in that case.
> > 
> > But even if you don't care about having to get everything, why is this
> > better than a couple of quick scripts that setup everything before
> > setting you free with a bunch of git modules?
> 
> Self-maintained scripts are prone to error, would need to make sure no
> future decision made in git development affects them, may mean an
> additional dependency (specially on Windows), etc

The only dependency I'd hope for would be sh. (and git) My belief is that if 
these scripts are kept simple, and basically never change, they won't be 
"prone to error". The whole point of being very light wrapper around git 
commands is that if the git commands fail, you can see and fix it.

These aren't essential to operation, they just help. There could be other ways 
to help windows users: initial tarballs with nothing checked out, for example.

> >> Oh, and regarding 'git clone --recursive', well, '--recursive' should
> >> be the default, not the option. IMHO it should be exactly the
> >> opposite: 'git clone --no-recursive' should be the option.
> > 
> > This really is a minor detail. You only ever have to clone once, so it's
> > not like it's a command you're going to be using every day.
> 
> (This is not KDE-related but git-related and should go to the git
> mailing list, but still...)
> 
> Let me disagree. That 'minor detail' is very easy to forget, specially
> when you don't know whether there are submodules. I only need to use
> 'git clone git://whatever.org/git/blah.git' when developing for other
> stuff, why do I need to know in advance whether there are submodules,
> then use --recursive or not? Sure, I could change my mind and from now
> on always do 'git clone --recursive ...' but, why should I? Given that
> there's nothing wrong with using '--recursive' when there are no
> submodules, heck, make it the default!

I meant it's minor for kde. Ignoring: feel free to take this to the git 
developers, obviously.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100129/88b2579e/attachment.sig