On Mon, Nov 23, 2009 at 12:11:29PM +0800, Adrian May wrote:
> As for gclient and repo, without pretending to be an expert on what
> they actually do, I'm getting a strong gut feeling that if what I'm
> trying to do is pull or push code, then that's about as close as you
> can get to a definition of source control's central purpose. In the
> days of cvs or svn, I'd expect to use the source control for that. How
> come git needs help?
> > these "bolt-on scripts" give the savvy user freedom
>
> Actually, I think their purpose is precisely the opposite: to regiment
> the ordinary developer into following their process. So having that
> code under the developer's control is a weakness.
If you don't have bolt-on scripts, and you move that into the the core
SCM, then you force *all* projects to use whatever workflow was
decided as being the One True Way of doing things as seen by the SCM
designer. So the question is whether the SCM *should* regiment all
projects into following the SCM's designers idea of the One True
Workflow.
Git's approach is to say that it will be fairly flexible about
dictating workflow --- who pushs to whom; whether there is a single
"star" repository topology, or something that is more flexible, etc.
You seem to hate this flexibility, because it makes life harder until
you set up these bolt-on scripts. But that's what many of us like
about git; that it doesn't force us (the project lead) into a single
way of doing things.
As far as my wanting to impose a particular regimen on my project's
developers, I've never been a big fan of the Bondage and Discpline
school of software engineering. They can use whatever workflow they
like; they just have to deliver patches that are clean. If they are,
I'll pull from their repository. If they aren't, I won't.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html