Re: [eigen] Mercurial and named branches

On Sun, Dec 6, 2015 at 4:08 PM, Ian Bell <ian.h.bell@xxxxxxxxx> wrote:

I've not seen others make this point before, so here goes: I think one issue that would also make me strongly argue in favor of git in the future is the support to add Eigen as a git submodule to an existing git project. Otherwise we have to rely on one of a few flaky hg->git mirrors on github to add Eigen as a submodule to a git project. A native git repo of Eigen would make integration into git repos much easier.

I have a lot of projects I am working on that use Eigen, and I've considered baking my own hg->git mirror to avoid this exact problem and to be able to be in control of the uptime of the bot.

So for me, git++

Ian

On Sun, Dec 6, 2015 at 1:53 PM, Jason Newton <nevion@xxxxxxxxx> wrote:
Well, to make sure its mentioned explicitly since most articles don't go here and instead focus on mostly functionally equivalent parts:

Git rebase is more powerful/safer/simpler in my experience than histedit/MQ. In two ways:
1) With the interactive mode, this lets me combine commits, recompose their content, reword messages and create a better history for upstream to see, after the feature I'm working on has matured a bit.
2) In normal mode, it lets me retarget what commit my work is being applied on to, making sure upstream will have no issues merging the branch in (particularly nice in fast moving repos, or when the feature takes a long time to develop).

It is very sleek and hard to screw this process up. With reflogs, you can always go back when something goes wrong. AFAICR, the hg variant of this was much more open to shooting yourself in the foot.

I find many projects, and an increasing number of them, expect you to do both of these, both in industry and FOSS because it makes the master repo much cleaner/straight forward. It also establishes a flow of how you work on a feature which is one of the things I cannot get to work equivalently in hg.

Further, git add -p, git gui, and git-cola, I can stage one hunk or (in guis) one line at a time very easily. This is incredibly helpful in making commits small and atomic yet allowing yourself to have some minor distractions along the way - say bug fixes.

I don't think this will become a religious hg-vs-git discussion, it's not that hot a topic and the it's easy to keep the discussion on functionality but I did want to take an opportunity to mention that while you are happy with the tool you've chosen, it doesn't seem to offer you any particular benefit to stay with (other than you already know it) and that a more popular tool exists which lowers the barrier of entry, and is arguably better (although from my own experiences I will say it is better). It's very difficult to put this kind of thing into a quantitative effect for contributions though - given that the majority of work for Eigen is done by Gael. But we can see that getting into Eigen development has one more cumbersome step to get into than need be of we accept that Git is more popular for researchers + college folk trying to contribute some work to Eigen, and it's not something they can learn the ins and outs of in 1 day.

-Jason

On Sun, Dec 6, 2015 at 11:47 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:

2015-12-06 7:58 GMT-05:00 Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>:
Hi all,

just tuning in, before this becomes a religious hg-vs-git discussion.

I doubt that there are any significant functional differences between them. For example, here are two blog-posts (by the same author), saying why each one is better:
http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/
http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/

Like these pages explain, the equivalent of git branches is hg bookmarks, not hg branches.

I do agree that the functionality between hg and git is similar enough, that for normal Eigen development, it makes no difference which DVCS we use.

The issue at hand here, though, might be something else than such a hard technical issue.

If the vast majority of people out there have settled on the git side, then using anything else, even if that has the same functionality but under different terminology (bookmarks vs branches), is a source of friction. The question is, what is worse: the friction of using a minority VCS, or the friction of switching VCS now? I honestly don't know!

Cheers,
Benoit

If you need to switch from one to the other, there are some nice equivalence-tables:
https://github.com/dotnetchris/Git-Hg-Rosetta-Stone/wiki#Rosetta_Stone
https://www.mercurial-scm.org/wiki/GitConcepts#Command_equivalence_table

About the original concern: hg, does allow using named branches for pull-requests. I agree with Gael that this is a bit overkill for minor changes (and it slightly messes up the history and makes bisecting a tiny bit more complicated in rare cases) -- but that is merely a policy-question and not an argument for or against hg. And as Gael suggested, if manual merging (or asking the pull-requester to redo the PR) is too complicated (or was forgotten), it is no big deal to close the named branch afterwards.

So overall, unless there are strong reasons for migrating to git, I would advice against it (very likely this will break some currently working things, such as links between bugs/issues/commits, etc). In contrast to the svn->hg conversion this won't add any essential new functionality (it merely would be more convenient for people mainly working with git).

If you do convert to git, I would not stop contributing, though (which I hope I will be able to do more frequently again in the future ...)

Cheers,
Christoph

On 05.12.2015 at 23:19, Nico Schlömer wrote:

I recently started using eigen more intensively, and I have to say that at
least for me it's true that mercurial is keeping me from contributing to
eigen more substantially. I've only used hg it a couple of years ago when I
was working with FEniCS [1]. They have switched over to Git a year or so
ago, and it's been a big winner for them (usability-wise, I'm not sure
about the community involvement). I'm contributing to around a dozen
projects on a regular basis, and for me it's most convenient if the project
is in Git (and almost a blocker if not), and even more so if it's hosted on
GitHub where I can easily fork and PR. (Also possible on bitbucket too, but
not as convenient I find.) Anyhow, he who codes decides; just sharing my
experience.

Cheers,
Nico

[1] http://fenicsproject.org/

On Sat, Dec 5, 2015 at 2:41 AM Jason Newton <nevion@xxxxxxxxx> wrote:

I'd say this is frequently the case for the people still holding out on
mercurial. I know I've repetitively had a good degree of cognitive burden
trying to submit things in a git/github fashion to the FOSS projects using
hg - my mind is fixated to the git flow and this flow breaks or has
encumbrances for competitors such as bzr and hg ... as far as I can tell
those tools are more restrictive and harder to work with to do things that
are a breeze in git.

I'd say there's many more people coming from git tools these days,
researchers and lab users included, in addition to the Whitehouse being
users . Have a look here: https://government.github.com/community/ , see
also https://github.com/whitehouse . I see folks from NOAA on the
numpy/scipy ML having repos hosted there too... I only see people in
industry using mercurial when they need a free account with 5 team
members. This is just github - actual usage of git is much higher with
atlassian even addressing it very seriously in their tools - atlassian
normally being the strongest enabler or focal point of mercurial usage I've
seen. So it is my very strong believe that you are indeed making it harder
for developers to contribute by having the additional burden of SCMs they
are not familiar with.

-Jason

On Fri, Dec 4, 2015 at 8:40 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
wrote:

Interesting. This seems to match the difference between notions of
'branches' in hg vs. git. I wonder if the people making named branches for
each pull request are coming from a git background and are learning hg just
for Eigen and expecting it to be like git. If this is the case, that could
mean that hg is now a hindrance for new contributors to Eigen, and if that
causes you to do additional manual work when merging pull requests, that
could mean that hg is then also a hindrance to you.

Benoit

2015-12-04 3:56 GMT-05:00 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:

Hi,

This is a note to the developers and contributors: please avoid named
branches as much as you can!

In our workflow, named branches are reserved to release branches, like
3.0, 3.1, 3.2, etc.

In any case, naming a branch for a single commit is ridiculous and
counter productive.

So here are some rules:

1 - If possible, ask occasional contributor to not introduce a named
branch for their patches.

2 - If a pull-request violates rule #1, then better do the merge
manually to bypass the named branch.

3 - If you don't known how to do #2, then at the very least do not
forget the --close-branch option when doing the merge from the command
line, and if you do the merge through the bitbucket interface don't forget
to check the "close branch" checkbox.

Thank you,
Gael

--
Dipl. Inf., Dipl. Math. Christoph Hertzberg

Universität Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Straße 1
28359 Bremen, Germany

Zentrale: +49 421 178 45-6611

Besuchsadresse der Nebengeschäftsstelle:
Robert-Hooke-Straße 5
28359 Bremen, Germany

Tel.: +49 421 178 45-4021
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: chtz@xxxxxxxxxxxxxxxxxxxxxxxx

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik