Re: [eigen] Mercurial and named branches

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