Re: preferring mercurial

[David Kastrup <dak@gnu.org>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Jordi Gutiérrez Hermoso writes:
>
>  > In hg the problem is much easier to solve without server-side access:
>  > just push another commit closing-branch commit on the extra head that
>  > you don't want to keep working on.
>
> You don't seem to understand what the problem is.  Consider an hg repo
> with 100 bookmarks, all of which suddenly point to completely
> different places -- or worse, places that at a glance look like where
> you should be but in fact are different.  Now figure out how to
> re-associate the 100 bookmarks with the correct dangling heads.  Why
> is this easier in hg than it would be in git?
>
>  > > Unfortunately, no.  The actual behavior of hg is indeed immediately
>  > > destructive in some cases, unlike git.
>  > 
>  > git has immediately destructive operations too, for example the
>  > "git reset HEAD --hard" that everyone blindly memorises (who really
>  > can keep all of the kinds of resets straight?)
>
> I haven't had any trouble. <shrug/>
>
>  > will destroy all unstaged changes.
>
> Indeed.  But unstaged changes aren't history yet, by definition.  (And
> in git staged changes are: there will be objects to match in the object
> database.)

Well, if they have not entered the reflog yet, they will be pretty hard
to dig up.  It's like handing someone a disk and saying "don't worry,
all the data is still there, only the inodes have been lost".

If we are talking about something like a private Bitcoin key (small and
very precious, hopefully identifiable), digging for it will be worth the
cost.

> DAK has threatened to contribute patches to git.

Oh, I did in the past speed up the diffing algorithm and made it use
less memory, so it's not an idle threat.

With regard to my threat of working on "git blame", I've got non-working
code doing most of the part.  I have just decided that the whole
algorithm does the wrong things in the wrong order, so fixing the
"remaining" bugs will lead to badly maintainable code of the "don't
touch this, it seems to work right now" variety.

So I am doing the core algorithm and data structures from scratch, and
that takes longer.

The problem is to stop somewhere before I rewrite all of git's
library...  But then I suffer from the "I can do better than _that_"
phenomenon pretty much every time I look too close at software written
by somebody else.  And if you don't manage to keep yourself confined to
messing with about a man*month's worth of messy code, you don't get
anywhere...

-- 
David Kastrup