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

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

[Adrian May]

Git is just plain wrong, because you can't split or merge repositories
or pull subtrees of them. 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. Will somebody please finish git itself instead
of working around it, or use a source control system that's up to the
job.

Adrian.

PS: In both cases, I had problems pulling the code.

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

[Johannes Schindelin]

Hi,

On Fri, 20 Nov 2009, Adrian May wrote:

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

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

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.

> Will somebody please finish git itself instead of working around it, or 
> use a source control system that's up to the job.

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

> PS: In both cases, I had problems pulling the code.

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

Ciao,
Dscho

P.S.: Feels fine to vent for me, too.

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

[Petr Baudis]

On Fri, Nov 20, 2009 at 06:51:32PM +0800, Adrian May wrote:
> 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?

				Petr "Pasky" Baudis

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

[Jakub Narebski]

Adrian May <adrian.alexander.may@gmail.com> writes:

> Git is just plain wrong, because you can't split or merge repositories
> or pull subtrees of them. 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. Will somebody please finish git itself instead
> of working around it, or use a source control system that's up to the
> job.

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

Do one thing, and do it well.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Clemens Buchacher]

On Fri, Nov 20, 2009 at 06:51:32PM +0800, Adrian May wrote:
> Git is just plain wrong, because you can't split or merge repositories
> or pull subtrees of them.

I think you made an unfortunate choice of words here, because as others have
mentioned, splitting and merging subtrees is implemented already. Maybe you
were talking about checking out or cloning subtrees. To date, none of the
distributed version control systems are capable of doing that. And that is
one of the reasons why we have wrapper scripts like repo (although IIRC repo
does a lot more than just that).

AFAICS, there is no fundamental reason why this should be difficult to
support. Clearly, there are some odd situations to deal with. For example,
how to deal with merge conflicts that happen outside of the subtree that's
currently available? How to detect (modified) moves of files into the
available subtree?

But we could simply fail in these cases. The workarounds currently in use
are not able to do this either.

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

I don't understand what you mean here.

> Will somebody please finish git itself instead of working around it, or
> use a source control system that's up to the job.

There is a desire to do this in the git community, as documented in [1].
However, it appears to be hard enough to do so that people had rather
implement custom solutions such as git-submodules, which are probably just
good enough for them.

Clemens

[1] http://git.or.cz/gitwiki/SoC2009Ideas#NarrowandSparseclonesupport

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

[Adrian May]

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

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

[tytso]

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

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

[Adrian May]

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

Of course I'd want the workflow configurable by whoever controls the
main repository. I couldn't possibly suggest that all git projects
need the same workflow. The number of developers can vary by five
orders of magnitude - that calls for different workflow models.

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

Leaving aside topology, I suppose we can agree that the subject
divides into two aspects: offering the developer some optional tools,
and asserting control over what gets commited to the official repo.
Perhaps we can also agree that the former belongs under the control of
the developer and the latter should be in the PM's hands. You seem to
have opinions about which of these two aspects is more or less
important, and to what extent git suffices, but I don't. I assume that
the project manager has his own opinions about both aspects and I'm
observing two big projects that independantly have augmented git's
features with their own scripts. Their docs talk about both aspects,
especially repo's, but they are entirely implemented in
developer-overridable scripts. So any repo functions to do with the
second aspect are either features that git needs to grow, or bits of
the git manual that the repo designer didn't read. I'd kinda like to
know which.

Returning to topology, I think that also divides up similarly. The PM
can't forbid you and me from casually swapping diffs back and forth,
but he can dictate who we are supposed to submit our final candidate
to for review. The very existence of a PM, who controls a subset of
the repositories in the world, already implies a star topology, and I
think pretty much everybody is using distributed source control in
this way, at least when it comes down to *controlling* anything.
People may also be causally bouncing diffs around, but that's not
control, it's communication. I've got a one-man project on github
which I edit from two locations, and even on that scale I find myself
working star-fashion because either computer might have junk
experiments in progress, but I only push to github if it's meaningful
and tidy.

That reminds me of a slightly different question: if a longer
experiment that I have committed several stages of turns out to be a
blind alley, I'd like to go back a few steps on main, declare
everything after that to be a side branch that I'll probably never use
again, and continue on main with my next attempt. Is that possible? I
know that I can just start a new branch from the before the bad
experiment, but if that happens a lot, the name of my current main
branch would be changing all the time, and I think that's bad. I
suspect what I want is possible, but I'm not sure how to do it.

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

Repo talks a lot about automating the workflow that leads to precisely
that decision. They evidently want something more evolved than
somebody simply having a look at the code. I'm not sure what they
want, but I'm pretty sure it's none of the developer's business.

Adrian.

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

[Bob Hazard]

Git's raison d'etre was to make merging cheaper.  You are encouraged
to make as many local branches as you want to experiment on features

"if a longer experiment that I have committed several stages of turns
out to be a
blind alley, I'd like to go back a few steps on main, declare
everything after that to be a side branch that I'll probably never use
again, and continue on main with my next attempt. Is that possible?"


Yes.

This google tech talk by Randal Schwartz is a little old but it might help

http://www.youtube.com/watch?v=8dhZ9BXQgc4



2009/11/24 Adrian May <adrian.alexander.may@gmail.com>:
>> 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.
>
> Of course I'd want the workflow configurable by whoever controls the
> main repository. I couldn't possibly suggest that all git projects
> need the same workflow. The number of developers can vary by five
> orders of magnitude - that calls for different workflow models.
>
>> 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.
>
> Leaving aside topology, I suppose we can agree that the subject
> divides into two aspects: offering the developer some optional tools,
> and asserting control over what gets commited to the official repo.
> Perhaps we can also agree that the former belongs under the control of
> the developer and the latter should be in the PM's hands. You seem to
> have opinions about which of these two aspects is more or less
> important, and to what extent git suffices, but I don't. I assume that
> the project manager has his own opinions about both aspects and I'm
> observing two big projects that independantly have augmented git's
> features with their own scripts. Their docs talk about both aspects,
> especially repo's, but they are entirely implemented in
> developer-overridable scripts. So any repo functions to do with the
> second aspect are either features that git needs to grow, or bits of
> the git manual that the repo designer didn't read. I'd kinda like to
> know which.
>
> Returning to topology, I think that also divides up similarly. The PM
> can't forbid you and me from casually swapping diffs back and forth,
> but he can dictate who we are supposed to submit our final candidate
> to for review. The very existence of a PM, who controls a subset of
> the repositories in the world, already implies a star topology, and I
> think pretty much everybody is using distributed source control in
> this way, at least when it comes down to *controlling* anything.
> People may also be causally bouncing diffs around, but that's not
> control, it's communication. I've got a one-man project on github
> which I edit from two locations, and even on that scale I find myself
> working star-fashion because either computer might have junk
> experiments in progress, but I only push to github if it's meaningful
> and tidy.
>
> That reminds me of a slightly different question: if a longer
> experiment that I have committed several stages of turns out to be a
> blind alley, I'd like to go back a few steps on main, declare
> everything after that to be a side branch that I'll probably never use
> again, and continue on main with my next attempt. Is that possible? I
> know that I can just start a new branch from the before the bad
> experiment, but if that happens a lot, the name of my current main
> branch would be changing all the time, and I think that's bad. I
> suspect what I want is possible, but I'm not sure how to do it.
>
>> 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.
>
> Repo talks a lot about automating the workflow that leads to precisely
> that decision. They evidently want something more evolved than
> somebody simply having a look at the code. I'm not sure what they
> want, but I'm pretty sure it's none of the developer's business.
>
> Adrian.
>
> --
> Chromium Discussion mailing list: chromium-discuss@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-discuss

-- 
Chromium Discussion mailing list: chromium-discuss@googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-discuss

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

[Daniel Barkalow]

On Tue, 24 Nov 2009, Adrian May wrote:

> > 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.
> 
> Of course I'd want the workflow configurable by whoever controls the
> main repository. I couldn't possibly suggest that all git projects
> need the same workflow. The number of developers can vary by five
> orders of magnitude - that calls for different workflow models.
> 
> > 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.
> 
> Leaving aside topology, I suppose we can agree that the subject
> divides into two aspects: offering the developer some optional tools,
> and asserting control over what gets commited to the official repo.
> Perhaps we can also agree that the former belongs under the control of
> the developer and the latter should be in the PM's hands. You seem to
> have opinions about which of these two aspects is more or less
> important, and to what extent git suffices, but I don't. I assume that
> the project manager has his own opinions about both aspects and I'm
> observing two big projects that independantly have augmented git's
> features with their own scripts. Their docs talk about both aspects,
> especially repo's, but they are entirely implemented in
> developer-overridable scripts. So any repo functions to do with the
> second aspect are either features that git needs to grow, or bits of
> the git manual that the repo designer didn't read. I'd kinda like to
> know which.

Repo (and gclient, which claims to be for SVN) seems to be mostly about 
the fact that nothing really handles submodules (independant projects that 
are also parts of larger projects) well. This is a known flaw with git, 
but it's unclear as to whether repo does better. It's probably best to let 
them work out a set of semantics which a real-world, full-scale project is 
happy with, and consider adopting it for native submodules when there's 
real-world positive experience behind it.

The other main thing I see repo doing is interfacing with gerrit, where 
your pushes get redirected, and there are a million review branches you 
can find on a web site, and where the server for a push is different from 
the best server for a mainline fetch. Some of this is probably worth 
having natively, but there's still the case of wanting to fetch a review 
branch based on understanding stuff about gerrit. This is similar to 
wanting to get a SVN revision out of bugzilla; you really want a tool 
that's particular to the integration of the systems you're using, not 
stuff built into your version control system. That said, if the submodule 
stuff were taken care of, Google could provide a git-review program, and 
do everything within the "git ..." wrapper instead of as an outer script.

	-Daniel
*This .sig left intentionally blank*