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

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

On Thu, May 9, 2013 at 12:14 PM, Jan Decaluwe <ja...@ja...> wrote:
> On 05/09/2013 08:49 AM, Angel Ezquerra wrote:
>
>> 1. mercurial supports anonymous branches (i.e. non linear branches).
>> This has the very good side effect of making the "pull" operation
>> completely safe, which is not the case in git I believe. Let me give
>> you an example:
>
>> The key difference here is that mercurial, thanks to its support of
>> anonymous branches can reliably represent what really happened (that
>> Alice's and Bob's histories diverged), while git cannot (since it
>> requires all branches to be linear).
>
> I think you are wrong here. You seem to suggest that
> git pull by default does a rebase, which is not true at all.
>
> git pull by default is shorthand for git fetch; git merge.

True, I was wrong. I thought that was the default behavior since I've
seen many git users do that. It is hard to tell what is the default
behavior of a given git command! A lot of git commands do many
different things depending on the flags they are provided. This means
that to get git to do some things you _must_ always call a git command
with a given set of flags (i.e. people always use some flags with some
commands, making them "default" behavior). I thought that was the case
for "git pull --rebase" (I think this is apropos:
http://stevelosh.com/blog/2013/04/git-koans/).

Note that I am a heavy mercurial user, but a very occasional git user,
so please take anything I say about git with a healthy dose of
skepticism, though :-)

> This would be similar to hg pull; hg update or hg merge if history
> has diverged.
>
> In both git and mercurial, a merge commit will be created by default.

That is not true, and probably is the key difference. In mercurial no
mew commit is ever created when you do hg pull and it is not done when
you do hg merge either. You must explicitly do hg commit to "confirm"
your merge (once you do it).

It is key that in mercurial the pull and merge steps are separate
commands. hg pull does not imply hg merge. Thus in mercurial you can
just pull some new revisions, inspect them, and when you want to can
do the merge (or a rebase if you are so inclined). Pulling new changes
is 100% safe, even if you have local, uncommitted changes.

If I understand how git works correctly, you could do the same thing
by doing git fetch. However I believe this is not what most people do?

So basically mercurial's default workflow makes it very easy to keep
both versions of history (Alice's and Bob's) "alive" until you are
ready to either merge them or rebase them. What I think (please
correct me if I am wrong) is git's default workflow (using "git pull"
rather than "git fetch") makes it harder, and if you use "git pull
--rebase" (as many people do) then it makes it impossible. So things
are notas as bad as I thought but still not nearly as safe as
Mercurial.

To sum up, I stand corrected, but I still think that mercurial is safer.

> If you want rebase in git, you do git fetch; git rebase. In fact,
> rebase is an alternative merging strategy, which I consider superior
> for local commits, because it keeps the history as it will be pushed
> out more linear.

I do rebase often, but I do so with the knowledge that it is a
dangerous, history destroying operation. That is why I don't think it
is such a good idea to encourage inexperienced users to use rebase.

That being said, mercurial is in the process of getting something
called "changeset evolution" which makes rebase and many other history
editing operations 100% safe (by hiding, rather than eliminating the
old, unrebased versions of the revisions). This is not ready yet, but
it should be ready in about 6 months.

> But again, this is not the default in git. It seems hg now has
> rebase as well, probably because more people realize it's actually
> a good and "polite" strategy to rebase your local commits.
>
> As I understand, hg makes rebase safer using phases, which I agree
> is a good thing, as one should never rebase commits that have been
> published already.

That is correct. Hopefully git will get the same functionality at some point.

Cheers,

Angel