On Sun, Mar 29, 2009 at 4:04 PM, Tom Metro <[email protected]> wrote:
> Version control is a mature space, with a lot of well established terms. It > feels like git developers tried to come up with new terms for common > operations in an attempt to make it clear that they have different behaviors > from what you're used to in other VCSs, but as a result there also seems to > be a bunch of things that are misnamed and misleading. Git's terminology appears to be consistent with that used by other DVCSes like mercurial and monotone. I've read that Linus seriously considered choosing Monotone instead of building his own, and git's design is highly influenced by it. there must be a tipping point where you reach your "ah ha" moment, and > then git feels intuitive and provides tangible benefits that speed > development. > I think the benefits are quick to be realized, like being able to work offline, *much* better performance overall, and just plain sheer flexibility. Of course, using and learning new and different tool involves some "transfer of momentum" and if that can't be done, sheer force of will. For VCS stuff, I didn't have much momentum. I used cvs in college and I've used svn as a non-developer in the past. However, when I started developing stuff that was destined for the outside world, I began searching for the "best tool for me". At my current $job we use svn, and I find myself frustrated with it on occasion, mostly because of speed, but also for silly stuff, like when I make a series of changes but forget to commit each separately and then have to do a stupid cut-and-paste dance to properly document each change. You sometimes hear learning object oriented programming as having such a > tipping point, where the programmer starts to thing intuitively in terms of > objects, instead of procedures. A similar experience can be found when going > from C to Perl. You can write very C-like Perl code, but not until you > internalize the Perl way of doing thing are you really gaining the benefit > of the tool. > That's probably true with using a DVCS, too. However, in my case, git was just in the right place at the right time, with the right features... I was a VCS n00b and wanted something that worked the way I think (a disorganized mess of parallel ideas that eventually sort out into something approaching clarity and order) > > So while I can now do multi-branch development with git, and it doesn't get > in my way for the most part, I haven't reached a "Zen state" with git such > that I feel it is providing any improvement for me over past VCSs. If I had spent my entire career using centralized VCSes then I can imagine that I would have a harder time using git. However, I didn't have very much to forget so it was easier. I would probably forget all about the "Zen" thing. When I came up with it, I was thinking about a term I picked up studying Aikido called "Zanshin" or "Beginners Mind". Zen is a term with (ironically, perhaps?) a lot of cognitave baggage, subject to interpretation in lots of ways. As I've worked on my outline and notes, I've decided that this will be mostly a spartan tutorial, with a brief introduction to the software (who/what/when/why/how) and then rolling up our sleeves to use it in a number of simple/common ways. If that goes quickly enough, I'll try to have some more advanced usage staged for demonstration, like cherry-picking and/or multi-tiered workflow. That will be interesting since I have not done it already myself, but the concept seems clear to me. If it's as simple as git's fans say it is, it's pretty impressive :) -- -- Steve Scaffidi <[email protected]> _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
