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 <[EMAIL PROTECTED]>:
> > > 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://[EMAIL PROTECTED]/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- is not svn, it is svn-. I mean that
> there is too much stuff that gets in the way.
Equivalent of svn is git . 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 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
