| Re: [eigen] Mercurial and named branches |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
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/
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