* Android needs repo, Chrome needs gclient. Neither work. What does that say about git? [not found] <2d707e8c-2561-470c-beba-c81e16ac441c@k17g2000yqh.googlegroups.com> @ 2009-11-20 10:51 ` Adrian May 2009-11-20 11:31 ` Johannes Schindelin ` (3 more replies) 0 siblings, 4 replies; 10+ messages in thread From: Adrian May @ 2009-11-20 10:51 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git? 2009-11-20 10:51 ` Android needs repo, Chrome needs gclient. Neither work. What does that say about git? Adrian May @ 2009-11-20 11:31 ` Johannes Schindelin 2009-11-23 4:11 ` Adrian May 2009-11-20 11:50 ` Petr Baudis ` (2 subsequent siblings) 3 siblings, 1 reply; 10+ messages in thread From: Johannes Schindelin @ 2009-11-20 11:31 UTC (permalink / raw) To: Adrian May; +Cc: git 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git? 2009-11-20 11:31 ` Johannes Schindelin @ 2009-11-23 4:11 ` Adrian May 2009-11-23 13:58 ` tytso 0 siblings, 1 reply; 10+ messages in thread From: Adrian May @ 2009-11-23 4:11 UTC (permalink / raw) To: git, chromium-discuss >> 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git? 2009-11-23 4:11 ` Adrian May @ 2009-11-23 13:58 ` tytso 2009-11-24 3:48 ` Adrian May 0 siblings, 1 reply; 10+ messages in thread From: tytso @ 2009-11-23 13:58 UTC (permalink / raw) To: Adrian May; +Cc: git, chromium-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git? 2009-11-23 13:58 ` tytso @ 2009-11-24 3:48 ` Adrian May 2009-11-24 11:29 ` Bob Hazard 2009-11-24 20:45 ` Daniel Barkalow 0 siblings, 2 replies; 10+ messages in thread From: Adrian May @ 2009-11-24 3:48 UTC (permalink / raw) To: tytso; +Cc: git, chromium-discuss > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git? 2009-11-24 3:48 ` Adrian May @ 2009-11-24 11:29 ` Bob Hazard 2009-11-24 20:45 ` Daniel Barkalow 1 sibling, 0 replies; 10+ messages in thread From: Bob Hazard @ 2009-11-24 11:29 UTC (permalink / raw) To: adrian.alexander.may; +Cc: tytso, git, chromium-discuss 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git? 2009-11-24 3:48 ` Adrian May 2009-11-24 11:29 ` Bob Hazard @ 2009-11-24 20:45 ` Daniel Barkalow 1 sibling, 0 replies; 10+ messages in thread From: Daniel Barkalow @ 2009-11-24 20:45 UTC (permalink / raw) To: Adrian May; +Cc: tytso, git, chromium-discuss 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* ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git? 2009-11-20 10:51 ` Android needs repo, Chrome needs gclient. Neither work. What does that say about git? Adrian May 2009-11-20 11:31 ` Johannes Schindelin @ 2009-11-20 11:50 ` Petr Baudis 2009-11-20 12:46 ` Jakub Narebski 2009-11-20 15:58 ` Clemens Buchacher 3 siblings, 0 replies; 10+ messages in thread From: Petr Baudis @ 2009-11-20 11:50 UTC (permalink / raw) To: Adrian May; +Cc: git 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git? 2009-11-20 10:51 ` Android needs repo, Chrome needs gclient. Neither work. What does that say about git? Adrian May 2009-11-20 11:31 ` Johannes Schindelin 2009-11-20 11:50 ` Petr Baudis @ 2009-11-20 12:46 ` Jakub Narebski 2009-11-20 15:58 ` Clemens Buchacher 3 siblings, 0 replies; 10+ messages in thread From: Jakub Narebski @ 2009-11-20 12:46 UTC (permalink / raw) To: Adrian May; +Cc: git 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git? 2009-11-20 10:51 ` Android needs repo, Chrome needs gclient. Neither work. What does that say about git? Adrian May ` (2 preceding siblings ...) 2009-11-20 12:46 ` Jakub Narebski @ 2009-11-20 15:58 ` Clemens Buchacher 3 siblings, 0 replies; 10+ messages in thread From: Clemens Buchacher @ 2009-11-20 15:58 UTC (permalink / raw) To: Adrian May; +Cc: git 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-11-24 20:45 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <2d707e8c-2561-470c-beba-c81e16ac441c@k17g2000yqh.googlegroups.com>
2009-11-20 10:51 ` Android needs repo, Chrome needs gclient. Neither work. What does that say about git? Adrian May
2009-11-20 11:31 ` Johannes Schindelin
2009-11-23 4:11 ` Adrian May
2009-11-23 13:58 ` tytso
2009-11-24 3:48 ` Adrian May
2009-11-24 11:29 ` Bob Hazard
2009-11-24 20:45 ` Daniel Barkalow
2009-11-20 11:50 ` Petr Baudis
2009-11-20 12:46 ` Jakub Narebski
2009-11-20 15:58 ` Clemens Buchacher
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).