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

[Steve Frécinaux <nudrema gmail com>]

On Sat, 2007-09-08 at 22:23 +0200, Olav Vitters wrote:
> 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.

You can use git as you use svn currently.
Just remember about git pull/commit/push and you're done.

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

This is just some terminology. A ref (reference) is a generic name for
tags and branches. 

> > > 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".

Such a tool is gitk which is really worth looking.

Note that I was also reluctant to use more than one branch for a
checkout directory, because I found it confusing and I was afraid about
build issues. But in practice everything works fine, and stuff like
ccache just makes it better. You are not likely to change many files by
checkouting another branch in typical usage (ie, closely related
patches), and nothing retains you from having a directory for each major
branch (say, gnome-2-16 and gnome-2-18).

Also, using several branches in a single directory allows convenient
things like saying 'oh, what I just coded doesn't belong to that current
patch, let's put it in another branch!'. Once you've created a branch
and commited your patch, you can rebase it where you want in the tree by
checkouting the relevant commit (for instance, the HEAD branch of the
remote repository) and applying the last commit on top of it (hopes it's
not too cryptic). Lastly it doesn't need you to have several copies of
the history, thus lowering disk usage.

But as I said, nothing forces you to have more than one branch per
checkout directory, and multiple directories, as you currently do with
SVN.

> > > > 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. 

Then you just do not create a new branch, commit when you're done on the
master branch, and push the patch once it is ready, or attach it to a
bugzilla bug using git-send-bugzilla [1]. Note that git allows you to
"amend" a commit, ie fixing it if you notice it is broken in some way,
as long as you don't have pushed it (very useful).

Also, something I do very frequently, is to have a branch for the change
where I commit often, and then "squash" it onto one single patch on the
master branch (equivalent to svn trunk) using git-merge --squash. This
allows you to have an history of your patch life, thus spotting
regressions easily and being able to get back to a previous version of
the patch. This is another advantage of being able to have several
branches in a single commit directory, as I'm pretty sure you already
ran into that issue using SVN...

> 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.

Equivalent of svn <tab> is git <tab>. The 'git' command is meant to be
the actual frontend (while git-* are mostly lower level commands, which
allow useful things like making your own scripts to do several things
automatically, as client-side hooks and such).

Well, git <tab> presents 140 commands here, but it's a bug in the bash
completion script, since git --help only gives 30 commands. svn --help
gives more commands than that.

> > 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.

You don't have to learn git either, it mostly depends on what you're
going to do with it. On my own, I began with the usual combo
clone/pull/commit/push, and only learnt about branches and stuff later.
But it's sure that understanding how things work under the hood helps,
as for any other (D)SCM. Yeah, don't you have an idea how SVN or CVS
work?

> > Even more pleasant as you "own" the cloned repo and nothing happens on
> > the central server until you really want it to.

That only single things is what makes DSCM so useful: you can edit your
own tree, share patches and patch series (what makes your history
cleaner and makes it easier to figure out where it broke), etc. without
much risks to break the central "stable" repository. jhbuild users would
thank you for that ;-)

That said, I'm sure I would advocate for git if we were to switch to a
D-SCM, but that doesn't mean I'm a strong partisan of switching *right
now*. DSCM get mature, but every one out there allow using svn as a
backend. It's just that SVN is quite limited feature-wise (no real tags,
no real branches, no merges) but it works fine through git-svn.