[crossfire] Crossfire should use Git

[Mark Wedel]

On 06/14/14 11:30 AM, Kevin Zheng wrote:
<snip>
> I believe the most compelling reason to use a DVCS is that it makes
> contributions easier. About a year ago a common complaint about my
> patches were that too many changes were lumped together in one patch,
> making it hard to review. While I could have used Git or Hg to make a
> local repository, I did not think that was worth the trouble.

  True - a DVCS certainly makes it easier to have/make multiple unrelated 
changes and make them available as individual patches (presuming good practices 
were followed and the developer remembers to check them in their local repo 
separately).

  I also think DVCS is also better if one is making really big changes that will 
take a while to do, because of the better branching, local commits, and merging 
- for something like SVN, you would pretty much need to make your own branch, 
which then also shows up in the main repo.

>
> Next, an adventure:
>
> I've taken the liberty to install and attempt to learn Mercurial.
> Since I am brainwashed by the Git world, please correct me if I'm wrong.
>
> My current workflow involves putting all non-trivial or multi-commit
> projects in a separate branch. Then I "dangerously" reorder, squash,
> and otherwise mutilate my local branch until it can be laid on top of
> the SVN trunk, where I dump back the linear history.
>
> If I used Hg, this would likely involve making many copies of the
> repository (since each branch is an entire checkout) for minor
> changes. Since I make extensive use of the Git staging area, I would
> wind up using `hg record` (an extension) very often. I would also end
> up maintaining patch sets using message queues (another extension), in
> order to clean up my changes before committing. In addition, it would
> be impossible for me to rebase my commits, which means that every
> branch would require its own merge. If you take a look at my commits,
> most have been squashed versions of local branch work.

  I'm not at all familiar with git, so I'm 100% how to compare the 2.

  I'm not 1005 sure why you would need many copies of the repository - there is 
nothing that prevents making a clone, making one set of changes, doing a local 
commit, making another set of changes, doing a local commit, and repeat as 
necessary.

  The only reason you would need many copies of the repository is if you were 
making different changes to each one - you could still do that with hg, but that 
seems like a somewhat odd way to develop code.

  Note you can reparent with mercurial quite easily - presuming there is a 
common parent, it is just a matter of doing 'hg pull <newparent>'.  You can 
likewise do the same with the push, but you need to be up to date relative to 
the parent (mercurial will make sure this is the case).

  All that said, at work, we use the cadmium extensions which provide some nice 
features like 'recommit', which collapses all the commits in the branch into a 
single delta which can be pushed later.  I'm not sure how available the cadmium 
tools are.  But whether people use extensions or not for mercurial doesn't 
matter much - those extensions are local to them, and the main repo doesn't 
really care.  So people can use whatever extensions work best for them.

>
> I advocated Git because "we should use the VCS that I'm most familiar
> with." It works with the workflow that I'm most comfortable with. I
> welcome anyone familiar with Hg to reeducate my current workflow. If I
> am the only developer that makes use of such a workflow, then I
> apologize for being selfish and greedy.

  The problem is that if I took that attitude several years ago, we probably we 
be on mercurial.  Crossfire is a community project, so has to meet the needs of 
many developers.  While SVN is pretty limiting, one thing it has going for it is 
that it is quite simple to use - non hardcore developers can understand and use 
git without much problem - from many of the other posts I've seen, that is not 
true with git (and mercurial for that matter).  So having something simple and 
easy to use has lots of advantages, with limited disadvantages (main one being 
that SVN is not a DVCS)

>
> Git has a good SVN bridge. Hg has a good Git bridge. Git does NOT have
> a good Hg bridge (Git's fault). If I keep my current workflow, then
> I'd much rather stick with SVN and play with local Git branches.

  IMO, that may just be the simplest way to go - I understand it is more pain 
for you, but there is a fair amount of pain to switch what VCS crossfire uses (I 
did this one before) - aside from the different commands people need to know, 
everyone also has to point to the new repo, you have to make sure there are not 
any outstanding commits, etc.

  Plus, from the other people that replied, there clearly was not an unanimous 
chorus of everyone agreeing to a move to git - granted the number of replies was 
limited, but if anything, seemed to be more opposition to it than those in favor.