Host AP/hostapd/wpa_supplicant repository and cvs vs. git

[Pavel Roskin]

Hello!

First of all, I'm very positive about switching to git.  After trying
git, CVS doesn't feel like a version control system at all ("cvs log"
doesn't do the right thing) and even subversion seems limited (where's
gitk for subversion?)

On Mon, 2005-11-28 at 19:57 +0100, Benoit Boissinot wrote:
> On 11/28/05, Leonardo Maccari
> <maccari-thisaintpartofmyaddress- at lenst.det.unifi.it> wrote:
> > It happened to me to try to work with git. I realized that the link I
> > posted it's the only documentation around, and while asking help to kernel
> > hackers I received this kind of answer more then once "I know how to use
> > git just for what I need it, and I really don't want to know more than
> > that".

That's OK.  git is a low level interface.  Nobody is supposed to know
all its commands.  I use cogito for almost everything.

> > So, before changing to git it might be a good idea to let it stabilize and
> > have some more docs.

Version 1.0 is around the corner.  The documentation is quite extensive.
Run "make doc" to generate manuals.  Run "make rpm" to generate rpm
packages including manuals.

Most importantly, git has been used for months on very serious projects
and I'm not aware of any data loss.

> If you want to look at the alternatives, maybe you can try mercurial [1].
> It has a good performance [2] (the initial goal was to be able to track
> the kernel) and the UI is easier to understand than git.

Mercurial is good, but I would prefer git for anything kernel related
just for compatibility reasons.

Also, mercurial is less popular, so hgk lags behind gitk, I'm not aware
of a qgit equivalent for mercurial (it looks like gitk, but works much
faster), and I haven't heard of anything like StGIT for mercurial (StGIT
allows to refine patches).

As for comparing the command line interface, mercurial should be
compared to cogito, and they are on the par (in my opinion).

-- 
Regards,
Pavel Roskin