Re: Git in a Nutshell guide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 19 Nov 2007, Benoit Sigoure wrote:

> On Nov 19, 2007, at 5:14 PM, Jonas Juselius wrote:
> >On Mon, 2007-11-19 at 17:05 +0100, Jakub Narebski wrote:
> > >Do I understand correctly that you don't support cloning via git://
> > >protocol?
> >
> >Yes, that is correct. The machine is behind a number of firewalls, and I
> >simply cannot be bothered to go through the bureaucracy...
> 
> You can create a repository on repo.or.cz then :)
> 
> As it is often the case different people happen to work on similar things
> without knowing each other.  I started http://repo.or.cz/w/tutorial.git which
> is meant to be a big Beamer presentation that presents Git thoroughly.  I
> wrote some ideas but didn't start to write the slides.  Just in case you want
> to have a look.
> 
> One of the things you said in your guide is that Git is easy to learn.  I
> think this is wrong.  Git is way more complicated than most other SCMs,
> especially compared to SVN.

I convinced my little company to switch to git (from arch, so take this 
with a grain of salt). I'd previously written a document explaining how to 
use arch, and I wrote a version for git, which said practically nothing, 
because everything I'd been able to do in arch is trivial to do in git. 
But I used the same format, anyway, to be sure to cover everything. I also 
told them to ask me if they were trying to do something and couldn't. I 
believe that all of the questions I've gotten were on how to use "advanced 
features" (i.e., things not included in my document because I never 
figured out how to do them with arch and decided to just live without), 
and people are using git successfully.

The main difference I see is that "save" and "publish" are separate 
operations with git and the same with other SCMs, but the separate 
concepts are obvious to anybody who's emailled a word processor document 
to somebody, and the distinction just has to be mentioned.

The challenge in writing a good introduction to git is leaving out 
explanations of all of the wonderful things that git can do that people 
don't expect to be within the abilities of an SCM. If you limit yourself 
to saying how to do things that SCMs can traditionally do, and therefore 
only explain how to do what people know they want to do, it's not to hard 
for people to learn. Of course, that's not enough to make good use of git, 
but it's enough to declare a transition from SVN or CVS successful.

I personally think it would be worth having a pair of documents, with the 
first being "everything you need to know", and the second being "things 
you'll find helpful that aren't strictly necessary".

	-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux