Steve Scaffidi wrote:
Tom Metro wrote:
Steve Scaffidi wrote:
- "the Zen of git - unlearn what you know"
I recommend that you use that as your talk title. :-)
It's apt, but perhaps not in the way you're thinking - At $work I
recently posted a wiki page about using git with our svn-based source
control and it attracted some attention - mostly from people who
simply don't see the value in distributed version control systems,
especially git. I tried explaining *why* I've grown to prefer using it
over svn... but most of these people seemed stuck on the fact that git
is new, and very much hyped-up and _supports_ a model of development
that they are not used to, never mind comfortable with.
However, if one forgets everything they think they know about git...
it turns out that just like SVN is a better CVS, git can be a better
SVN! And... when you need to do some things that SVN can simply never
support (at least not without substantial effort)... chances are you
*can* with git.
So your point was not to unlearn what you know about past version
control systems, but to unlearn the hype you've heard about git?
What I've found is that you can be a casual user of git, and hardly
notice the difference between it and svn. Sure, the commands are
different, but that's where the "svn to git" cheat sheets that are
floating around on the web will get you by. I used git in this fashion
for a few years, because that's all I really needed from it at the time.
I wasn't an active developer on the projects, so as long as I could get
at the desired revision of the source, it suited my needs.
More recently I worked on a project using git as an active developer,
where all the usual functionality becomes required, like branching and
merging, and this is when I started having disagreements with git. It
didn't take long to develop an intuition about how CVS, and later SVN
was going to behave, and develop a mental picture of how it worked. I've
been told that you have a better chance of developing a similar
intuition of git by reading about its internals, so I read "Git
Internals"[1], but while the book started off good at explaining the
more basic internals (the elegance of storing complete snapshots, rather
than diffs; , it fell short once it started talking about branching and
merging, and never really tied that back to the underlying functionality.
1. http://peepcode.com/products/git-internals-pdf
As a result, I find a number of thing that git does to be unintuitive.
For example, when you add a file in git, it doesn't just queue that file
to be included in the next commit (as would happen in SVN). It commits
the current state of the file to your local "index" (a misnamed database
or storage area) immediately. If at some time later you run 'git diff'
you'll only see changes made to the file since it was added. Not only
does this not make intuitive sense to me, I've yet to see an explanation
for why such behavior is useful. This applies equally to a number of
other git behaviors.
Git also has a lot of terminology baggage. 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.
The reason why I think your "the Zen of git - unlearn what you know"
phrase is appropriate, is because if you start with the assumption that
at least a good portion of the git fans are using it because it works
better, than 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.
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.
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.
-Tom
--
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
