Ohad Lutzky wrote:
Of course it would. But this one puts a lot of candy down that same
path as well. These mines hurt, but are not fatal (again, from my
experience, all mistakes can be recovered if detected within a
reasonable time), and git's features make it, IMO, worth the trouble.
For example, while many people find the staging area confusing (you
have to "add" a file you've changed again in order to commit it, or
just use commit -a to automatically add all changed files), it allows
git to do awesome stuff like "git add -p"; this command goes over the
differences from the previous version (like git diff), and asks you
which hunks to stage. This means you can make a set of changes,
realize it can be logically split into two, smaller sets of changes,
and proceed to commit it as two sets of changes. Or, for a more common
case, it allows you to stage only your actual fix to the commit
without the various debugging statements you've added across your code
in order to track down a bug, and do a quick "git reset --hard"
afterwards.
There's a succinct list of reasons I like git
here: http://whygitisbetterthanx.com/
I'm getting the sense that this conversation has gone off the main track
a little. This is, I'll admit, also my fault. The question here is not
"which VCS is better" (for which my answer, if you look at it, is
"depends"), but "which VCS should we teach in the dev lecture of the W2L
series".
Here's the thing. When you first start to use a new system, what you see
is mostly the mines. If this is the first system of its kind, you are
likely to run into mines that are not really mines, but your
misunderstanding of what the system is supposed to do, but still, the
mines (real and conceptual) are mostly what you see. You do not,
typically, see the candies, for the very simple reason that you do not
understand the system well enough to appreciate or make use of them.
As you use of the system matures, you learn to change your thinking to
not regard some things as mines, and avoid the real ones. As that
happens, the mines become less and less important, and the candies
become more and more interesting. The main pre-requisite for that
happening is that YOU HAVE NOT GIVEN UP ON THE TOOL!
This thread started around a very specific question - should Haifux
teach git, or some other version control system, as part of the
development tools lecture. Any answer should take into account that
amount of time given for this part of the lecture (between 10 and 20
minutes), and the amount of tutoring the students will have down the
road (none unless they seek it). Under those conditions, in my opinion,
git is the wrong tool because:
* Anyone who has any experience with VCS will, likely, have used
server based ones. Git, for them, contains all of the
misconception mines that go with a distributed revision control
* Git has some actual bone-fide mines, lain on the path traversed
even by relatively basic VCS operations.
* None of the candies matter, as you only have 20 minutes (best
case) to show them the tool and set them on their way, and the
candies require the user to "get" version control in order to be
appreciated.
With the amount of time you have, you will be lucky to get 20% to
appreciate the fact they can restore any version they checked in in the
past. Showing them git because it can split a single change into
multiple commits will fly so far over their heads, I'm afraid none of
them will even run a single git command to even check out the water.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com
_______________________________________________
Haifux mailing list
[email protected]
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
