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