Shipping hg-git by default?

[anatoly techtonik]

On Mon, Sep 28, 2015 at 1:47 PM, Kastner Masilko, Friedrich <
kastner-masilko at at.festo.com> wrote:

> From: anatoly techtonik [mailto:techtonik at gmail.com]
> >
> > That's the thing I am trying to fix. My incentive is to waste less time
> on fighting with workflow by using tools that provide the best user
> experience for me.
> > So far Mercurial was winning. But I frequently patch things on a freshly
> > deployed box and setting up and tuning Mercurial for working with Git is
> more
> > hassle than just launching Git + StackOverflow in separate window.
>
> I don't understand that. Either you have an incentive (using the better
> workflow provided by Mercurial), or you have none. What is it? Or was it
> just a rhetorical vehicle to threaten developers with another lost user?
>

Let me explain what my workflow is. First, I am not a coder. I am not
writing things from scratch - I patch and fix things that others are
already written. And I do it only when it is necessary - when there is a
problem. And that problem is often only visible in some remote environment,
provisioned automatically with some scripts, which are not mine.

So, the workflow is:
 - ssh to remote server
 - debug stuff, make modifications
 - clone upstream source
 - copy modified files into upstream
 - commit

Sometimes I recreate the remote environment from scratch to better debug
the problem. The classic:
 - provision node
 - get the source
 - init
 - debug
 - commit

Because scripts are not mine, Mercurial is not included. And I like to work
with MQ rather than with live commits. I have plenty of debug info stored
in a separate queue and applied only when necessary.

For Atlassian, this can be a killer feature over GitHub - maintaining your
patches and rearranging them from web interface.


> Mercurial is not winning, Git is. If there ever was something to "win",
> that is. As things are now, Git provides the best user interface for
> working with GitHub and yes, even Bitbucket.


The best experience is delivered by tools such as
https://desktop.github.com/ and not by standard Git. Note that there is a
difference between user interface and user experience. You may have the
best user interface, but that doesn't guarantee you have the best
experience with it. Like I use command line a lot and GUI tools are slowing
me down.

However, I used it as full-fledged bridge only once, ran into a multitude
> of problems (different hashes, history rewrite is a PITA, no octopus
> merges, etc.), and stopped using it that way.
>

Different hashes can be a problem when you need to reference revisions, but
I never faced with this problem until you said it. Probably hg needs to
mention Git revision number when mirroring remote repo, but it may happen
that the problem is premature.


> Using Mercurial on Git-based projects just for the sake of using Mercurial
> smells too much like Dogma-Driven-Development for me TBH. The workflows are
> not that much different, just Git's command-line is ugly as hell.


That ugliness is the core of the problem. I tired of
http://stackoverflow.com/questions/popular/git?show=alltime&sort=votes&pageSize=50


> On the subject of including hg-git in the default installation I'd like to
> point out that hg-git is dependent on dulwich AFAIK. If a change in Git
> breaks dulwich functions, you'd have to hope that the dulwich project gets
> updated quickly, so you can include it in your extension that is included
> in the main project.


I tend to think that Linux guys are good at architecture that preserves
backward compatibility.
-- 
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150929/c86aa65d/attachment-0002.html>