<div dir="ltr">I tend to agree that git is somewhat complex for the novice. It takes awhile<br>before one feels comfortable working with git. SCMs in general, are not considered<br>"core" learning material, so most student will prefer to avoid "wasting" their<br>
time to earn the required expertise.<br><br>Having said that, for the experienced git users, there is not reason to lose<br>their work, even in the case of some mistake.<br>For example, most problems can be recovered using:<br>
<a href="http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#recovering-lost-changes">http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#recovering-lost-changes</a><br><br>Another, less powerful tool, but good enough for immediate disaster recovery is the ORIG_HEAD reference.<br>
<br>--doron<br><br><div class="gmail_quote">On Thu, Oct 15, 2009 at 11:38 PM, guy keren <span dir="ltr"><<a href="mailto:choo@actcom.co.il">choo@actcom.co.il</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
the problem with git, is that it's very easy to shoot yourself in the<br>
foot. giving it to students, who might accidentally reset their<br>
repository into losing their code, is not a very good idea, if you don't<br>
have time to give a proper explanation plus warnings.<br>
<font color="#888888"><br>
--guy<br>
</font><div class="im"><br>
Tzafrir Cohen wrote:<br>
> On Thu, Oct 15, 2009 at 09:13:58PM +0200, Eli Billauer wrote:<br>
>> OK, I think this is a good time to express my view regarding the<br>
>> "Development tools" lecture. It's purpose, as I see it, is to give the<br>
>> students a nice start with the "right" tools for developing code, as<br>
>> needed for their exercises. If their experience is good, they'll stay.<br>
>> If not, they'll soon use the alternatives.<br>
>><br>
>><br>
>> If you want to give a lecture about any other subject, as a<br>
>> Stay-in-Linux or mainstream lecture, by all means come forward. But<br>
>> let's try to get some focus on the initial lecture.<br>
>><br>
>><br>
>> Correct me if I'm wrong, but a student is not likely to go beyond a<br>
>> project which runs on a single platform, having a few source files, and<br>
>> with no more than two or three persons involved. Hence autotools are<br>
>> irrelevant, and so are version control systems. Tarballing all sources,<br>
>> and sending to your partner with comments, is as much version control as<br>
>> you need in these situations.<br>
><br>
> I'm not sure I agree with you regarding version control systems.<br>
><br>
> Specifically distributed version control systems make the common case of<br>
> a repository for the project simple. Unlike Subversion, you don't need<br>
> to set up a separate server.<br>
><br>
> And it saves you a whole lot of time in saving ex1.c_1 , ex1.c_2,<br>
> ex.c.orig and such. I think that demonstarting simple linear workflow<br>
> (no branches, no remote repositories) with git, bzr or hg could be handy.<br>
><br>
<br>
</div><div><div></div><div class="h5">_______________________________________________<br>
Haifux mailing list<br>
<a href="mailto:Haifux@haifux.org">Haifux@haifux.org</a><br>
<a href="http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux" target="_blank">http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux</a><br>
</div></div></blockquote></div><br></div>