Re: [myhdl-list] Keep hierarchy in VHDL conversion

[Angel E. <ang...@gm...>]

On Mon, Apr 15, 2013 at 2:52 AM, Christopher Felton
<chr...@gm...> wrote:
> On 4/14/13 2:48 PM, Angel Ezquerra wrote:
>> On Sun, Apr 14, 2013 at 9:28 PM, Jan Decaluwe <ja...@ja...> wrote:
>>> On 04/14/2013 06:02 PM, Angel Ezquerra wrote:
>>>
>>>> Oscar,
>>>>
>>>> if you have never used mercurial and need some help drop me a line. I
>>>> am very active in TortoiseHg development (and a bit on mercurial as
>>>> well) so I think I could help bring you up to speed if you need it
>>>
>>> Interesting.
>>>
>>> Perhaps I should ask a more general question: should we
>>> consider to move MyHDL development to github?
>>>
>>> This is not a technical question. Many Pythonistas probably
>>> have a slight preference for Python-based mercurial.
>>> Professionally, I use both and I am happy with either one.
>>>
>>> The point is that "everyone" seems to be at github. So
>>> perhaps this is good for visibility.
>>>
>>> It may also be good for development. I like the way
>>> Oscar presented his work: it shows commitment to
>>> maintain the feature, and everyone can try/follow
>>> it without requiring my assistance. Much better
>>> than getting patches/bundles out of the blue that
>>> I am supposed to review/check/integrate before others
>>> can (easily) do so.
>>>
>>> Of course, for this to work, all development should
>>> be on the same system.
>>>
>>> Jan
>>
>>
>> As you an imagine given my background I really like the fact that
>> MyHDL is developed using mercurial, which I greatly prefer over git.
>>
>> This is a bit off topic but I personally find the fact that so many
>> technical people use and even advocate git rather than mercurial both
>> surprising and a little depressing, since (IMHO) mercurial is a much
>> better all around version control system (_much_ better UI, better
>> tools, better Windows support, better, simpler model, etc). I think
>> github is a big reason why git is more popular than mercurial (at the
>> time github was created, there was nothing quite like it, unless you
>> count SourceForge...) but the real reason is probably the fact that it
>> was created by Linus... I guess we technical people are as prone to
>> decide things based on non technical reasons as anybody else...
>
> Can you outline some of the technical pros?  From what I have been
> able to gather it is somewhat subjective.  It seems both projects
> have been influence each other resulting in technical equals.

Before I start I want to first state that I am way more knowledgeable
about mercurial than about git. As I said I contribute to mercurial in
addition to using it everyday (for work and for my own stuff). I have
much less experience with git, but I believe I have enough to judge
both systems on their merits.

With that being said, and taking into account that everything I say
here is just my humble opinion and that my git-fu is not nearly as
good as my mercurial-fu...

/rant mode on :-)

In truth both systems are more similar than they are different. Both
are excellent distributed version control systems with a pretty
similar technical foundation. This makes sense since both were
originally designed to solve the same problem, notably, the
replacement of BitKeeper as the version control system for the Linux
kernel. Both had their first version publicly released pretty much
simultaneously (withing a couple of days I think) and both were
created by notable Linux kernel hackers (although obviously one of
them is the most notable and famous kernel hacker of them all :-) ).
Both handle and use pretty similar concepts, even though some of the
user facing names they use are not the same (e.g. git branches ˜
mercurial bookmarks).

However, precisely because they are so similar, the few differences
they have become very important. In particular:

1. Git's UI is atrocious: Tens of commands, some of which do pretty
much but not quite the same, some of which do 2, even 3 totally
different, almost unrelated things depending on the command line
arguments; commands which by default do the "wrong" thing (i.e. you
must always use a particular combination of command line parameters to
do the right thing), etc (Steve Losh recently made a funny and just
slightly togue in cheek blog post about this title "Git koans":
http://stevelosh.com/blog/2013/04/git-koans/).

Another thing which is a bit of putting and a symptom of a lack of
clear UI design (although in practice is not a big deal) is the fact
that most git's commands are in their own shells scripts or programs
(rather than a single stand alone command).

If you compare git's command line UI with mercurial's command line UI
the difference is like night and day. There are very few important
mercurial commands (init, clone, commit, update, pull and push) and
each of them does one main thing, and it does it by default (no extra
parameters needed in the usual case). There are other mercurial
commands (add, remove, revert, etc) and all commands have some options
but you do not usually need to use them.

In a funny, kind of perverse way I think this is one of the things
that made git so popular. Git is so hard to use that once people
finally manage to master it they feel a sense of accomplishment which
compels them to write / blog about it. Why are there so many git
tutorials? Is it because git is cool or because it is hard? People
seem to think that the huge number of git tutorials and git blog
postsare due to git being very popular. That is partly true, but I
think the real reason is because it is just hard.

Mercurial on the other hand is just easy (for a version control
system). People just learn to use it and get on with their work. There
is no need to brag about it because there is nothing to brag about.
This is also what makes (again, this is _all_ IMHO) many git users so
fiercely defensive when you criticize their tool of choice. To them
git's UI is not bad, it is just they way it is. If you don't like it
it is because you do not get it. The fact that you must understand
git's internals to get anything serious done is not bad, it is
awesome, etc, etc. It is as if they suffer from some sort of Helsinki
syndrome :->

2. I find that most git GUI tools are poor compared to mercurial's
equivalents (despite their developer's best efforts). This is a direct
consequence of the poor git command line UI. This is not due to a lack
of competence on the git GUI tool developers (which I respect and even
sympathize with). It is due to the fact that they must somehow map
git's command line UI concepts into a sane GUI, which is _very_ hard.
Basically they are between a rock and a hard place because they can
either expose all the rich git functionality at the cost of a complex
UI or they can have a simple UI but lose a lot of what makes git
powerful. I do not think that is as much the case for mercurial GUI
tools and for TortosieHg in particular. I cannot claim that TortoiseHg
is perfect (it is not) but I think the fact that the underlying
mercurial command line model is so clean makes our job of exposing all
of mercurial's power much easier.

3. Git is _very_ Unix-centric. This may improve in the future, given
that Microsoft Visual Studio will soon get built-in git support, but
even then git on Windows relies and will continue to rely on MinGW. A
lot of the things that make git fast are only true on Unix (specially
on Linux).

On the other hand, mercurial is truly cross platform and runs on
windows natively (thanks to it being mostly written in Python).

4. In mercurial, history is "sacred" and "append only" by _default_.
You can easily edit history, but this is discouraged in many subtle
ways, such as the need to manually edit the history editing extensions
(such as mq and rebase). In git, editing history, even _other people's
history_ is not only possible but almost encouraged. I find that is a
big red flag for a version control system. In addition, mercurial is
getting built-in and _safe_ history rewriting commands (this is still
a work in progress, but it is almost done) which add a way to create
new revisions that "replace" old revisions while still keeping the old
revisions around (for more info, check
http://hg-lab.logilab.org/doc/mutable-history/html/).

5. mercurial has cheaper branching that git. This may shock some
people because git users usually claim that that git's branches are
much cheaper than mercurial's. When they say so they often also
mention that mercurial branches are "clones". If you hear that then
you can stop listening to whoever says it because he has not used a
less than 3 year's old mercurial version. Mercurial now has 4 ways to
branch: clones, named branches, bookmarks and anonymous branches.
"mercurial bookmarks" are pretty much the same as "git branches"
although there are some small differences. There are no named branches
nor anonymous branches in git. Anonymous branches are the cheapest
branches of all because you do not need to create them explicitly.
They just happen and you can deal with them as you want. They are a
very powerful and simple concept which (as all in this rant) IMHO let
mercurial capture what really happen when two contributors do
different things based on the same point in history.

6. Mercurial is easier to extend. Its hook and extension system is
very easy to use and give you a lot of power. You can use external
programs but you can also use python and when you do so you have
access to all the mercurial's internals. This has the drawback that if
the mercurial internals change you may need to update your extension,
but in my experience this is rarely necessary.

This is not to say that mercurial is perfect or even better than git
in every way. Its "submodule" support (what mercurial calls
"subrepos") can be (and is being) improved for example. The way it
handles tags is perhaps a little confusing (although it makes sense
when you understand it), etc. Git's clones are often a bit smaller
than mercurial's and git is a bit faster than mercurial on Linux. I
don't think these small advantages are significant enough for most
users, and that mercurial is just the better overall tool.

I've personally had to introduce a lot of people to mercurial (several
tens of people, probably about one hundred). Many of these are
hardware and firmware engineers (the kind of people that MyHDL could
target) for whom a good version control system before learning
mercurial was zip + Skype. I had a very easy time helping them get up
to speed with mercurial. I shudder to think how hard it would have
been to help them reach the same level of proficiency with git.

/rant mode off

> I have found some short coming with git and my work flow but I assume
> that was me being less familiar with git than hg.

I'm curious to know about your experience. Care to share?

Cheers,

Angel