Re: Git vs SVN (was: Can we improve things?)

[Olav Vitters <olav bkor dhs org>]

On Sat, Sep 08, 2007 at 04:47:31PM +0300, Kalle Vahlman wrote:
> 2007/9/8, Olav Vitters <olav bkor dhs org>:
> > On Sat, Sep 08, 2007 at 05:56:38AM -0400, Kevin Kubasik wrote:
> > Let's summarize it as: I don't know any D-SCM :-) (only investigate by
> > checking out docs)
> > (but I am also not interested in learning a SCM)
> 
> Hopefully that doesn't translate "I don't know and I don't care"...

It translates to: I really care about not needing to learn an SCM.

Take for example the output of 'git'
  push          Update remote refs along with associated objects

That to me is a 'wtf?' (1.5.2).

> > For me, I consider the "you don't change directories for each branch you
> > make" a drawback. I find directories as branches easier to understand (I
> > hated this in CVS).
> 
> There's some tools to visualize the branch history in git, which
> includes more information than just "this is a branch".
> 
> > > mkdir projdir && cd projdir
> > > git clone ssh://kkubasik git gnome org/git/coolproject/kkubasik
> > > git branch newcoolfeature
> > > git checkout newcoolfeature
> >
> > I don't like this checkout step.
> 
> You can merge it with the branch command if you like:
> 
>   git checkout -b newcoolfeature

It is not about one command. One dir per branch is perfectly
understandable for me. 

> > > <write an awesome feature>
> > > git commit -a
> >
> > Is the confusing way removed? If I do git-<TAB> I see 'Display all 144
> > possibilities'. Why so many?
> 
> Because that's how git is structured. It's a collection of little
> tools to do specific tasks. You'll likely use 4-5 of them in normal
> developer tasks. Also, invoking 'git' gives you the most common ones.
> If you do svn<TAB> there's only one useful command out of 9 (on my
> machine) and it doesn't tell what it does either just by looking at
> the name. Does that really mean anything?

Equivalent of git-<TAB> is not svn<TAB>, it is svn-<TAB>. I mean that
there is too much stuff that gets in the way.

> And furthermore, looking at git commands is absolutely the worst way
> to start learning git. Specially when coming from SVN, git commands as
> they are will make no sense at all. But, when you read up and look at
> few pretty pictures about how git works (like in
> http://eagain.net/articles/git-for-computer-scientists/ ), they start
> to make sense and you'll see how they turn SCM from just storing
> snapshots of file states to actual tool for managing a project and
> it's changes.

I didn't have to learn SVN.

> And this all is naturally from the developer/maintainer POV, as
> translators and documentors do not benefit from this as much. But as
> the general opinion seems to be, they shouldn't be forced to use SCM:s
> directly anyway.

That is a theoretical discussion. Ideally GNOME has a D-SCM now and all
translators use a websystem that automatically translators. It doesn't
exist. Although there is now some progress towards D-SCM, I don't see
such a websystem happening. Also am not sure if a websystem is the most
appropriate way.

> > Easy stuff should be easy, hard stuff
> > should be harder (otherwise the easy stuff is confusing). I never liked
> > CVS, but I like SVN.. easy to understand.
> 
> There was great commotion about people not wanting to switch to svn
> because they had to learn new SCM. I bet nobody today wants to go back
> to CVS though, and it is bound to be the same for the next step too...

Git is not SVN. On the Bugzilla account, I started out with:
  alias cvs='svn'
because I wanted to prevent someone typing in the wrong commands. It is
pretty similar (CVS/SVN commands). There is no need for me to learn a
D-SCM. I'm perfectly happy if git commit would first try to commit
remotely, and if that fails, locally. That is the kind of D-SCM I'd
like (probably pretty unique in that).

> > Anyway, I think you forgot the 'push'.
> >
> > > Now you have 2 branches (the original, and newcoolfeature) where new
> > > cool feature has your changes.
> >
> > Is it easy enough if you want to avoid branches? I usually work on
> > trunk, nothing else (I do understand people want better merging than
> > available in SVN).
> 
> Even more pleasant as you "own" the cloned repo and nothing happens on
> the central server until you really want it to.
> 
> But I guess that's for the "newbie-committee" to decide if there ever
> will be one...

-- 
Regards,
Olav