Re: Repository conversion

[Tait <gnu...@t4...>]

Daniel J Sebald <dan...@ie...> said (on 2014/03/03):
>  From my understanding, the reason that git is more flexible in terms of 
> modifying past comments as pointed out by Mojca is fact that the 
> underlying manner in which files are stored in git is as complete files, 
> albeit hash files.  On the other hand, hg uses a series of diffs.  Thus 
> hg is in more sense "immutable".

I wouldn't get hung up on the difference between snapshots vs. change
sets. Assuming everything is working correctly, the two should be
equivalent. (If anything, I would say that capturing exactly the state of
the repository as it was for the developer making the commit is more
"immutable", but either approach will achieve the same end result.)

>                       ...  So, once a push is done and considered 
> public, it is best to be immutable.

This is true for either Mercurial or Git.

> ...                    For me, the two differences that stood out when I 
> compared git and mercurial years ago (git I have limited exposure with 
> since):
> 
> 1) I found hg's syntax more understandable and less cumbersome.  I 
> didn't like the staging area concept of Git because it felt repetitive, 
> although I'm sure there might be some simple ways of circumventing this 
> staging area because git does provide so many options/configurations. 
> So please point out if that is still true and a big difference between 
> the two systems.

Terminology is different (update vs. fetch/pull, clone vs checkout, etc.)
but these hurdles are trivial and will be forgotten within a couple of
weeks anyway.

The staging area and index still exist in git, and as I mentioned before,
it is a big difference that sets git apart from other tools. It is
possible to set up git aliases and habits to make the index (aka staging
area) less apparent, but if it's possible to forget the "bad habits" of
CVS and SVN one may find the index is not just useful, but essential.
There is convenience: often one finds themselves working on more than one
thing at a time, or realizing midway through a change that it ought to
instead be multiple, smaller pieces. But also there is the philosophical
argument: one ought to deliberately construct a commit, not have it thrown
together as the summation of whatever -- intentionally or not -- happens
to be different.

The counterargument, as you've pointed out, is that I can be careful and
manage my work tree myself to construct the commits I desire, thank you
very much, now please stop making me repeat myself.

I guess the agnostic would say that in one case the tool relies on you to
manipulate the filesystem to create the desired changesets (that's
Mercurial), and the other provides tools to more directly craft the
desired commit state (that's git).

> 2) Mercurial has a built in html server that I really like.  Does git 
> have that now?  I really like being able to go to some project's 
> repository online and there is that similar, nice interface for finding 
> info about recent changesets, browsing code, viewing file history, etc. 
>   That really is an important part of source control.  (One of the 
> nicest VCS's in terms of visual navigation is a commercial product, but 
> isn't a distributed VCS but more along the lines of cvs.)

Git has had a built-in web server for a long time (since mid-2006). It's
a functional, albeit not terribly pretty interface. That's balanced out
by git having much better local tools for finding info about changes,
browsing code, viewing file history, and so forth so relying on an
external web interface is not necessary. These days, github may well be
the best-known "web interface" to git, but it's obviously tied to github.

In gnuplot's case, that interface is provided by SourceForge, and the same
regardless of tool choice. So I don't think this is really a factor in the
decision. And even if gnuplot moved away from SourceForge, the
public-facing web interface would most likely not be provided by the one
built-in to either git or Mercurial.

> Recently I've discovered tortoisehg which is a very nice interface for 
> Windows users especially.  I assume there is a tourtoisegit as well. 

Yes. And other implementations that similarly integrate into the Windows
shell. And projects for Eclipse. And the usual command-line clients in
either msys or cygwin flavors. I don't think there's any noteworthy
difference between the two on this front.

> So, for Windows developers, hg and git look-and-feel differences might 
> hardly matter.

I don't think preferences among Windows developers will be any less
intense or uniquely personal than any other OS. No UI will make one
indistinguishable from another unless it forgoes the best parts of both,
leaving only a lowest common denominator. (And then, why not just stick
with SVN?)

>                 Also, a good merge tool is worth considering, but I 
> think that might independent of the git/hg question.

I'm not sure if you mean a tool for visualizing and managing diffs and
merges manually, or the algorithms driving merging within the VCS.

For the former, I've recently discovered Meld (http://meldmerge.org), and
I rather like it.

For the latter, git uses true 3-way and N-way merging, with some choices
of variations to those algorithms. Mercurial is using a true 3-way merge
as well now, although nobody seems to know what algorithms they use to do
it. (Darcs' more complex patch and merge algorithms seems to be considered
the best, fwiw.)



At the risk of carrying on too long, here's some questions you didn't
ask:
1) Why do we have version control? Who uses it?  What do they expect out
of it?

2) What's the normal work flow in the project? How are bugs fixed (to the
current version, previously released versions)? How are new features
added? What are the things that work really well or really poorly about
this process?

3) How are outside contributions accepted? (How often does this happen?)
Who deals with these, and how? What works really well or really poorly
about this process?

The answers to those questions are important, I think, to picking git or
mercurial.