Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?

[Adrian May <adrian.alexander.may@gmail.com>]

>> Git is just plain wrong, because you can't split or merge repositories
>> or pull subtrees of them.
>
> You are plain wrong, because that is possible.  Did you maybe forget to do
> your homework before coming here and shouting around as if you were right?

So it is. Fair enough, I stand corrected. That was my single biggest
gripe about git so it's nice to know it's there.

> To the contrary, these "bolt-on scripts" are superior to other solutions,
> because they give the savvy user freedom to do _anything_ a program can
> do.
> Your complaing have the same sense as complaining that gcc does not
> include functionality of Makefile, because you just can't manage
> larger projects without it (or equivalent).

Well, these scripts, whatever git is written in and pretty much
everything else in sight is a Turing machine, so anything could, in
theory, do anything. But nevertheless, I think everybody agrees that
certain functions belong in certain places, even if they disagree
about where. I'd wager that 'make' belongs outside of gcc because it
also drives other compilers, things like yacc, post-build steps, etc.
OTOH I think producing browse info is a long-standing ommission from
gcc that should never have been done externally in things like ctags
and cscope, because the compiler has to do 90% of the work required
anyway and because it's the compiler's opinion that counts.

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? Basically, my point is that these scripts should
be the roadmap for git itself, because those are the functions people
had to add to their git-based set-up in the real world. Also because
the implementations would probably be simpler, more robust and more
general if they were in git.

> 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.

As for pulling subtrees, I guess it's sensible for the code managers
to declare which subtrees are likely to work on their own by making
them repositories. I believe you can also link lots of repositories
together to make a huge combo-repository, so I don't understand why
android doesn't use that instead of having this script to iterate over
them all. Maybe they started before the split/merge thing got written
(it would have been risky to try and get it right first time if they
couldn't rearrange them later.)

>> It doesn't have the kind of triggers you
>> need to assert change control either, and these bolt-on scripts are
>> just making life messy.
>Can you elaborate?

Well, I believe that repo is largely about asserting their code
integration process. It knows who to send your changes to for review.
But now that I think about it, I guess git does that as a first
principle. If I push to your repo, you get to review it before it goes
in and in the meantime I shouldn't be surprised that our repos look
different. So what the hell do they write those scripts for? Does
anybody around here know if they actually need them or not?
Unfortunately their list doesn't seem to be taking my post.

> If you had problems pulling the code, there are two possible sources of
> problems: the program or a PEBCAK.

Well, the repo thing eventually got fixed: it was committing suicide
at the first sign of server load. I don't know what gclient's problem
is, but my personal opinion is that the *root* problem is the
existence of the scripts at all. In both cases, there's not much room
for pebcak in the instructions.

> You obviously do not understand Open Source.  If you have an itch, scratch
> it, or pay somebody to scratch it for you.

I know, but I'm actually supposed to be getting on with my real job
instead of sticking my nose into other peoples' problems like this. I
might also argue that making suggestions is some kind of contribution,
at least if the value of the suggestion outweighs the distraction of
everybody having to read it to find out whether it's any use or not,
which may or may not be the case here. Either way, I also have a
budget for distractions and it doesn't allow for getting my brain
around the git source code.

Adrian.