[ECOS] Replacing CVS - decision time: part 2

[Jonathan Larmour <jifl at jifvik dot org>]

After the previous discussion, I felt the only way to get real clarity 
on remaining sticking points, is to actually try out mercurial and git 
on Windows - given the past discussion, particularly to exercise git. I 
have spent some time now on Windows (for my sins) trying out hg and git, 
both in command line form and via some of the GUI interfaces. Again, 
personal bandwidth (especially due to easter holidays) intervened and it 
took a while to do.

While it's true that the most important thing is for the maintainers to 
be comfortable with the VCS, this isn't an overriding consideration - I 
also think it's very important for users, and more importantly 
(potential) contributors, to be using something that is good quality, 
not overly complex, easy to pick up for the most common use-cases, and 
fits with their own development requirements. Whatever we choose will be 
what most of them will use themselves. And whatever anyone thinks about 
*nix versus Windows, it's a known fact that the clear majority of eCos 
users use Windows for day-to-day development. That's why this 
investigation is important.

In trying them out, I've also been trying out both in rather less 
straightforward situations than I did before too.

On Windows, mercurial or git could be cygwin or native; I tried out 
cygwin in both cases, but for git I also tried out msysgit which is its 
native version (which includes GitGUI as well as gitk). I also tried the 
Tortoise interfaces for both. I happened to be using Vista, which is a 
complete PITA unsurprisingly, but that affects both equally. All the 
versions used, including cygwin, are the latest stable released versions 
(not counting the fact that all msysgit releases call themselves "preview").

One of the first things I did, to be representative, was to convert 
eCoscentric's public hg mirror to git using hg-git. That way I could 
operate on appropriate data reflecting the size of the eCos repository. 
I initially tried converting it on windows. That was a mistake. It took 
hours and repeatedly failed (whinging about checksum errors). Instead I 
was able to do it completely successfully on Linux and copy it over to 
the windows machine verbatim, without any problems.

Anyway, here are my resulting impressions after experimentation:

- Cygwin git is indeed fairly slow - subjectively it feels slightly 
slower than cygwin hg (perhaps because it tends to move whole blobs and 
therefore more data around, and I/O is something cygwin is bad at?). I 
wasn't able to quantify this, but suffice to say that they're roughly 
comparable for most small operations. That said, a git clone of the 
whole ecos repo was 40s faster on my machine, although 40s isn't much 
really.

- Cygwin git was occasionally (rarely) unreliable and just crapped out 
with an exception, although to be fair that could be cygwin.

- As Alex/Oyvind reported, cygwin git+ssh is broken - appears to xfer
objects but then says "The remote end hung up unexpectedly" and aborts.

I did check, and cygwin hg works fine with ssh, so the problem is 
specific to git. This is quite a serious problem if we had any 
contributors on windows and we wanted them to be able to push directly.

- Despite what Alex said, msysgit did seem to generally work
(v1.7.0.2-preview20100309 at least). However, you can't really share it 
with cygwin.

- In general I found my experience of git on Windows was that I was left 
feeling frustrated (not all of that was specific to the fact it was on 
Windows!). Some things were far harder than they should have been to 
discover. The man pages would definitely be confusing for many - they 
are filled with odd terminology, opaque nomenclature and jargon, e.g. 
"Porcelain commands" and "alternative porcelains" and many git-specific 
concepts which are only understandable once you already know git, like 
what it means by "index" or the staging area, refs, etc. The man pages 
are the only real form of git documentation directly supplied, and if 
they were confusing to me, it's not a good sign for others. Non-native 
english speakers would have even more trouble.

So quite often when I was having difficulty, I was having trouble 
finding answers. Such as the syntax of git repositories accessed via 
git-daemon, if I want to push to them using an absolute path.

I often found other people also had the same difficulties and confusion 
as to how to do something, and I was repeatedly finding answers at 
StackOverflow fortunately. But if git users have to rely on sites like 
StackOverflow to get answers, I don't think that is a good thing :-/.

- To serve on hg, it's just hg serve. With git it's hard to find out how 
at first, and then according to
http://stackoverflow.com/questions/377213/git-serve-i-would-like-it-that-simple
it's:
git daemon --reuseaddr --base-path=. --export-all --verbose
then after subsequent mysterious grief I find out it needs to be
git daemon --reuseaddr --base-path=. --export-all --verbose
--enable=receive-pack
otherwise pushes don't work (although I've found out there are security 
caveats with this form too, so to do it really properly you have to do 
something more complicated than that).

Yes, there is some documentation for git-daemon buried in the man pages, 
but under the "internal plumbing" section which I wouldn't have 
expected, and it certainly doesn't describe the significance of 
--enable=receive-pack or what it means (yes I know now).

- While having 'git cherry' should be useful, showing only the sha1
commit ids as output is a terrible UI choice - I suspect it reflects the
desire of git to be a toolkit which can be munged by shell scripts. 'hg
outgoing' is much better as it's more descriptive.

- TortoiseGit has definite rough edges (signs of it being work in 
progress), and some operations such as obtaining log messages take an 
unexpectedly long time.

- I could not get TortoiseGit's Stash save and pop to work properly - it 
kept claiming the tree was dirty while also claiming there were no 
differences, no matter how many times I rescanned.

- Msysgit's Git GUI is not bad if you already happy with git 
terminology, concepts, and expected workflow, otherwise it may be confusing.

TortoiseHg has Repository Explorer, which IMHO uses less obtuse terminology.

- TortoiseHg relies more on repository explorer for operations, rather 
than being able to choose operations directly in the context menu. 
Although the most common operations are there. TortoiseGit has a long 
list of operations directly in the context menu. In the context menu is 
arguably more efficient, although the list is quite long. In a separate 
application is arguably better structured and may lead to better 
workflow (as you may be doing more than a single operation), but 
slightly less efficient.

- gitk is good, as is the hg repository browser equivalent - no real
difference either way. Repository explorer is essentially equivalent to 
a mixture of gitk and git gui, rather than having them as separate tools.

- TortoiseGit does make it straightforward to do dangerous things which 
lose history. Maybe for some people this is a glass half full thing.

- TortoiseHg's "annotate" (same as blame) shows you which revision is
associated with which line, and although you can click or hover over a
line to see who did it (rather than just the revision number) you have 
to right click the menu headings to see the user in the normal way. Not 
a big deal, but they don't make it clear.

- A big issue to me is that msysgit's Git Gui appears to *automatically*
(i.e. without asking) convert an almost random subset of files from LF 
to CRLF line endings, even when those files weren't modified by the user.
This may affect either the contributions we get from windows users, or 
the ease which windows users can make contributions. Now this probably 
came about for me because at installation time you have to set it up 
with either:
1) checkout windows line endings, commit unix; or
2) checkout as-is and commit unix; or
3) checkout as-is and commit as-is

For my testing, I chose the default of (1) which is also the 
"recommended setting on windows for cross-platform projects". That's 
what I assume most people would do because it's the default and it's 
recommended for our situation. (2) would probably in fact have been the 
better option, but unfortunately, once installed, there seems to be no 
way to change things (except by uninstalling and reinstalling which is 
rather lame). It's still no excuse really for converting some files 
without asking or prompting.

Unlike the equivalent hg extension for crlf/lf management, there are no 
per-file or file extension overrides I could see in msysgit.

Cygwin git will treat everything equivalent to (3) above. There's a risk 
that CRLFs may get introduced if someone uses an editor which doesn't 
treat the file as having only LFs. It's certainly more likely for newly 
created files, such as in new ports. Stripping these out would be more 
pain for the contributors and/or the handling maintainer (if they even 
remembers at the time).

- GitGUI seemed to make a lot of other change noise too, not just CRLF 
conversion, but also changing file modes. It would be a pain for people 
to have to keep working around this sort of noise.

- I experimented, and unlike what I had been informed before, I could 
not reliably make git determine file parents from partial file matches. 
Only renames, or renames with relatively minor mods (with high 
similarity scores according to git). Doing things like splitting up a 
file may lose parentage (whereas in hg, you can do an hg copy first, and 
then cut down each file, and then the link to the parent is maintained).


I guess people will now be able to pick up a vibe about my feelings on 
git versus hg now that I've finished this experimentation :-/, but I'm 
trying to still present my observations straightforwardly.

Nevertheless, once anyone wants to comment on anything above, then the 
maintainers should get on and decide. Unless someone suggests something 
specific, I doubt I'll be doing any more investigative analysis.

Jifl

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss