I've had only a limited opportunity to use git, but I recognized something about it pretty quickly -- something which I think is behind some of these strong differences of opinion. Basically, git takes a different approach to project source control -- it "thinks" about the problems in a different way. To use it properly you have to think the same way. When you do, the way to respond to a particular situation is obvious precisely when it seems arbitrary to someone thinking in more traditional terms, and documentation is clear and helpful where those who haven't learned the new perspective find it confusing and worthless. What makes the problem worse is that the same word may actually mean something subtlty but importantly different, while a new term is frequently interpretted mistakenly as being "pretty much the same thing" as a more familiar term. Whether this new way of thinking is better, as the supporters claim, is yet to be seen. Clearly, it is a barrier that needs to be taken into account in any changeover, but which, I think, can be lowered with a set of well documented procedures and scripts designed for the particular repository design. For those who want to pass through this kind of looking glass, the most important advise is 1) Don't assume that you know what is meant by any term or phrase, whether familiar or not; 2) Concentrate on descriptions of "here's a problem and here is how you-could/we-did solve it"; 3) Resist the temptation to assume people are doing something stupid -- always presume that people actually know what they are talking about (sometimes they don't, of course, but even then they are likely to be less stupid than it might appear and you'll usually learn more making the same mistake than trying to avoid it). I haven't, by the way, been able to cross the conceptual threshold for git myself yet, but this is a pattern I have seen frequently in software innovations -- the "symptoms" are clear, and -- worthwhile or not -- I'm confident that there really is stuff going on that I don't understand yet. The most relevant example to this group was back when almost nobody had heard of object oriented programming and some of us tried to promote it and explain just what it was ("Your making a big deal out of nothing -- 'objects' are just data structures, 'methods', are just fancy procedures, and its much more flexible to use cut-and-paste than 'inheritance'."). And, of course, this is pretty much THE forum for "generic programming". Some other major examples I've seen is the "Real Programmers use assembly language" battle and the "structured control flow" battle (a battle so thoroughly won, that most younger prgrammers don't seem to know the term or, even when they do, have any real concept of the alternative; yes, I remember when "if ... then ... otherwise..." -- not yet "else" -- was unusual in programming languages, or was considered just some occasionally handy "syntactic sugar"). Topher
On 7 March 2012 19:21, Robert Ramey<ramey@rrsd.com> wrote:
Christopher Jefferson wrote:
On 7 Mar 2012, at 16:10, Philippe Vaucher wrote: This is the biggest problem with git -- there are a hundred tiny things to learn which are hard to find when you do not know what you are looking for.
This is a big problem with all software these days
More so with git than its rivals.
_______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost