We used to have a linear-history policy when we started with mercurial
-- obviously mistakes where made over time (and I'm definitely not happy
with that when browsing through the history, doing bisects, etc)
At least for trivial changes all relevant information should be
contained in the commit-message itself (of course one question is until
when is a change "trivial")
I found the setting (under "Settings/General/Merge requests"). There is
also a semi-linear history option (essentially the same, but with a
merge-commit), which might be a compromise to at least avoid commit
graphs spanning over hundreds of commits).
Especially, once we seriously start with CI, I totally agree that having
all relevant information of the PR available would be great.
Other opinions?
Christoph
On 05/12/2019 19.15, Joel Holdsworth wrote:
That's not typical usage in GitLab.
The main reason not to is that it will destroy the information from the MR.
If you do a merge, it will include any text I write in the MR
description, the user who submitted the MR, the comitter, the MR's ID
etc. - which is all useful information for record keeping.
If you cherry-pick my commits you will lose all that.
It would make sense to keep the commit history if it were linear from
the start like the Wine project's Git repo, but for history which
already has many merges, I don't see much benefit, personally.
Joel
On 12/5/19 6:07 PM, Christoph Hertzberg wrote:
I don't seem to be able to rebase/fast-forward merge this (I don't
like polluting our history with trivial changes).
@Gael: Are there any project settings which need to be done for that?
Christoph
On 05/12/2019 18.57, Joel Holdsworth wrote:
Ok - it's working now. Here is MR #1 !
https://gitlab.com/libeigen/eigen/merge_requests/1
Does it deserve such a momentous designation? You be the judge.
Joel
On 12/5/19 5:27 PM, Christoph Hertzberg wrote:
I should have checked for new mails, before sending my last.
I just granted you Reporter rights (as well as to two other people
who requested access -- I did not grant Developer access, of course).
I think the manual approval of new members won't be as tedious as
the previous procedure of granting access to our bugzilla. And
having a manual step with a small time delay might be a good way to
avoid bug/PR-SPAM.
Cheers,
Christoph
On 05/12/2019 18.16, Joel Holdsworth wrote:
Ok... manual approval sounds tedious. I would recommend figuring
out a way to automate the approval e.g. with a button on the
website. Otherwise, it's just pointless admin for you guys.
Anyway, my username is "jhol", so can you make me reporter?
Joel
On 12/5/19 5:07 PM, Gael Guennebaud wrote:
On Thu, Dec 5, 2019 at 5:33 PM Joel Holdsworth
<[email protected] <mailto:[email protected]>> wrote:
Hi Gael!
Thanks for this. It's going to make my work so much easier.
I just wanted to resubmit my int8 ostream patches, but it
seems that I
dodn't have permissions to submit a merge request. Do you need
to open
up the MRs to non-members?
thank you for trying. I was indeed unsure whether MR was open to
anybody. According to this page:
https://docs.gitlab.com/ee/user/permissions.html, MR is open for
"reporter" members only, meaning that we'll have to manually
approve people wanting to join the project to propose MR.
For the record, compared to "guests" (aka everybody for a public
project as Eigen), reporters have the following additional
permissions:
View Security reports
See a list of jobs
See a job log
Download and browse job artifacts
View confidential issues
Assign issues
Label issues
Lock issue threads
Manage issue tracker
Manage related issues
Manage labels
Create code snippets
See a commit status
See a container registry
See environments
See a list of merge requests
View project statistics
View Error Tracking list
This seems OK to me.
gael.
Thanks
Joel
On 12/4/19 9:17 PM, Gael Guennebaud wrote:
>
> The critical steps of the migration are done. I've thus made
public the
> new repo:
>
> https://gitlab.com/libeigen/eigen
>
> I've also re-opened the deprecated mercurial repo on
bitbucket so
that
> people can smoothly migrate their clones, links, etc.
>
> Please report any outdated links and mercurial/bitbucket
references
> you'll find. I'm already aware of some pages on our wiki,
like:
> -
>
http://eigen.tuxfamily.org/index.php?title=Developer%27s_Corner<http://eigen.tuxfamily.org/index.php?title=Developer%27s_Corner>
> - http://eigen.tuxfamily.org/index.php?title=Mercurial
>
> Any help on updating those old documentations will be greatly
appreciated!
>
> Gael
>
> On Wed, Dec 4, 2019 at 9:04 AM Gael Guennebaud
> <[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
>
> Hi,
>
> as planed we'll start the migration to GitLab today. This
means that
> the Eigen's bitbucket project
(repository+pull-requests) won't be
> accessible within a few minutes. Same for our bugzilla
that
will be
> turned as read-only.
>
> Wish me good luck and see you soon for announcing the
availability
> of the new git repository!
>
> Cheers,
> Gael
>
--
Dr.-Ing. Christoph Hertzberg
Besuchsadresse der Nebengeschäftsstelle:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany
Postadresse der Hauptgeschäftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 1
28359 Bremen, Germany
Tel.: +49 421 178 45-4021
Zentrale: +49 421 178 45-0
E-Mail: [email protected]
Weitere Informationen: http://www.dfki.de/robotik
-------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
Trippstadter Straße 122, D-67663 Kaiserslautern, Germany
Geschäftsführung:
Prof. Dr. Antonio Krüger (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Dr. Gabriël Clemens
Amtsgericht Kaiserslautern, HRB 2313
-------------------------------------------------------------
