[crossfire] Crossfire should use Git

Fri Jun 13 18:11:11 CDT 2014

On Fri, 13 Jun 2014 09:52:02 -0400
Steven Johnson <shjohnson.pi at gmail.com> wrote:

> I'm not a regular contributor either but I believe mercurial (hg) is
> the better choice as well. Plus the site Bloody Shade mentioned
> http://hginit.com/ easily explains the transition from svn to hg.
> On Jun 13, 2014 9:29 AM, "Bloody Shade" <bloodyshade at gmail.com> wrote:
> 
> > I'm not sure I can agree with a move to Git, personally.

I am not a fan of git.  I had a co-worker that used it and expressed
pros of a distributed VCS.  I agreed in principle with various ideas.
At one point, I decided to try git out for maintaining a web site that
was deployed on multiple servers (test/production).  I stuck with it for
two weeks.  It was a horrible two weeks during which I wasted much time
dredging through horrible documentation to figure out how to do
seemingly basic things.  The sheer number of commands was a huge
put-off.  I destroyed my repository multiple times while learning.
At one point, I wanted to do something that was easy peasy in CVS
and SVN, but it was a brick wall in git.  I researched for hours, and
ultimately learned git will not do it.  Though I could have obliged
git's (IMO) retarded limitation quite easily, my experience was so
hard already, that I decided then and there to try either bazaar or
mercurial instead.

I learned that mercurial (at that point) had the same issue as git
with respect to the particular operation I wanted to do (add an empty
directory).  I don't know that this is presently an issue with
mercurial, but it tipped the balance for me.  I tried bazaar.

In less than an hour, I converted my git repo to a bazaar repo and was
using bazaar painlessly ... it worked just like I felt it should based
on my years of experience with CVS and SVN.  After two weeks of using
git this never happened.

If crossfire wants casual users to be able to use the VCS, then I cannot
recommend git.  If crossfire wants to limit VCS use to git-heads, then
go ahead.  A CVS/SVN/BZR user can pretty comfortably go from one VCS to
another.  I'd guess the same is true of Hg.  It is clear to me that git
is a horse of a different color.  It solves a particular problem that
does not fit most software project needs at the expense of being an
easy to use tool.

I am sure that one day it is almost inevitable that I will have to use
it and be comfortable using it, but I will put off that day as long as
I can.

> > There's plenty of drawbacks that also come with git (not that other
> > version controls don't).
> > I personally use mercurial (hg) for my projects and you can find
> > more info on it and see if you like it at: http://hginit.com/
> >
> > I found this article with some things I also don't like about git,
> > in case anybody else is wondering (although I'm sure there's more):
> > http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/

Right on.  Excellent article.

> > Then again, I'm not a regular contributor, so feel free to ignore
> > this, but I thought it would be worth throwing my 2 cents.
> >
> > On 6/13/2014 10:13 AM, Kevin Zheng wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hi all,
> >>
> >> Crossfire originally lived in the world of CVS, until a handful of
> >> brave knights ventured to move it to SVN. Today I believe it is
> >> time to move again, and this time to Git.

I actually asked to get access to crossfire VCS at this time.  I did
not know SVN.  The transition from CVS to SVN was easy.  I did learn,
however that I choose not to use SVN when possible, but whatever I
dislike about SVN is small compared to what git brings to the table.

> >> Git is a distributed version control system, which means that
> >> checking out an old revision or reading the commit log does not
> >> require accessing the sometimes painfully slow servers on the
> >> Internet. Each 'clone' of the repository is a fully-functioning
> >> repository on its own. This means that developers, even those who
> >> do not have commit access, can work on projects at their own pace
> >> and submit them with tools such as `git format-patch` and others.
> >>
> >> Git makes branching easy. It makes maintaining them manageable. As
> >> an example, several important fixes were made in 'trunk', which
> >> have yet to be backported to 1.12.0. In addition, there are no
> >> release engineering branches, which means that each release is
> >> simply cut from the next 'trunk' state in line. Even "trivial"
> >> fixes could benefit from topic branches, but SVN does not make
> >> this easy, convenient, or fun. Using Git branches would help
> >> create a more stable codebase by improving release engineering and
> >> adopting intermediate "stable" branches that servers can track. A
> >> recent autotools bug that wiped server configuration files, for
> >> example, could have been prevented if changes on the bleeding edge
> >> were evaluated by test servers first.
> >>
> >> Git is not terribly difficult to use. Right now I access the SVN
> >> repository through a local Git clone, but this is inadequate
> >> because I cannot publish my topic branches (without considerably
> >> difficulty). A migration that preserves tags, branches, and full
> >> revision history can be made as fast as the revisions are pulled
> >> from SVN.
> >>
> >> In summary, a few important benefits of using Git:
> >>
> >> - - Contributors can work on the code easier, with revision
> >> control.
> >> - - Distributed, so works without (slow) Internet access.
> >> - - Encourages branching -> more stable codebase.
> >> - - Easy to use and migrate to.
> >> - - Full (all revision history) repository size: 21.7 MiB
> >> (server), 13.9 MiB (client), 106.1 MiB (maps)

I disagree with the assertion that git is easy.  Sure, it's easy to
checkout someone's project to compile.  After that its not easy.
Just because someone that uses it a lot is comfortable with it does
not make something easy.  Things are easy because they follow well
thought out patterns that are echoed in other similar softwares or
products.  git breaks the mold.  It is a beast unto itself.

All these "git pros" are not git-specific.  They are distributed VCS
pros.  I dare say that bazaar and mercurial bring the same pros to
the table with much fewer cons.  I know that bazaar sadly seems
largely dead.  I feel it is the best dvcs that does not force a user
to work a certain way.  It has some pain points, but I choose it
still.

I not tried Hg because I haven't a need.  I'd try it in a heartbeat
if an interesting project used it.  I have no interest in git.  I've
had enough pain in two weeks.  To be fair, I have had a bit of pain
with bazaar, but nothing like with git.  Distributed VCS brings a
lot of complexity to VCS that doesn't exist for CVS and SVN.

> >> However, there are a few immediate problems:
> >>
> >> Most projects using SVN make extensive use of the revision number
> >> identifiers. Crossfire is no different. Git has revision (commit)
> >> identifiers, but they are meaningless without the repository,
> >> whereas SVN increments the number for each commit. I do not
> >> believe this is an issue, because client compatibility is not
> >> determined by this specifier, plugin versions are only checked to
> >> match, and other uses of the identifier can be removed.
> >>
> >> Of course, comments, questions, and hate mail are always welcome.
> >>
> >> Thanks,
> >> Kevin Zheng

2 cents also, from a formerly active contributor.  Use of git will
discourage a change from "formerly" to "once again".  Just saying.
And yes, I do version control heavily at work.  I go out of my way
to use a VCS for server configuration management, etc.  The dislike
is not for lack of experience, but rather because of a lack of
inexperience with other VCS.

Kevin