Re: [eigen] GitLab migration is starting now! |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] GitLab migration is starting now!
- From: "Janek Kozicki (yade)" <jkozicki-yade@xxxxxxxxx>
- Date: Thu, 5 Dec 2019 19:40:48 +0100
- Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAALVBMVEUBAQEtLS1KSkpRUVFXV1dYWFhjY2Nzc3N3d3eHh4eKioqdnZ24uLjLy8vc3NxVIagyAAAACXBIWXMAAAsTAAALEwEAmpwYAAAAB3RJTUUH2AIVEzgS1fgQtQAAAjRJREFUOMtt1DFv00AUAOAzFQNbjigSyoQaRaBMhKgLUyKXpVNNeUpk9vyDqFJhQ1kiBuaqAwJCqvPtSLY7RlTn5+5IdnYkkt/AOyfxXVLe5vf53Z1875kd34tOEax8djmj6GyjhB5bxz50GdsVZr9fqRjZwAtKOJw5Wqs2MMZ16ALHsaDncF7xAHix1oEFHAB8f+pRjcO4gfZDykcYzbiucRolOLUJ6kjA0xtVt+A6TySlM0RajIpK6DzwKZ/nOYbF/gclHMo1ZOHYY/+Ha+AWuM+3oMS4eeqYzZ8FiCltgUqI8cd2wwAVpJk+8LWYjBtnJdQpHQqJMd4Oxt4bU9ESiFGc5hkqaH74asAX4iabP5I5gZ+qjgGlJCqZa3h3lxhoeVcSE1qLQC4sqKOK9MGW9E3izFqqHokoztLFEgXg31sbZEKnWi2T74A4NxfVQqlkjKtcAWD+zcArFEES01dR0E/nnV0IgugmDd/2L84sOAouRBBHEc7gtc8teDkRlE0iNQPo2w3Xhh/D4TCIQ4LRLoTvgwjj6RRgavdurxYGMaIuGOyAW/PpNlCcU9/93AHenAWYjPoAwa+G3e3to/MgFNTAEKvKDjzuCzHTnY3qqdXtx24VijzQfZ0yewZ5cwRFQaa+mIYr1uI0I76+3W4xhlvoVRwOA0Fdl64HlJnxP6T8YpX/Lga4Wv4A3ErrU5oTfN7Mu/llXMl8RXEPji/lQkN3H7qXqgC2By47EXeU/7PJ/wPxRKMnuZwIeAAAAABJRU5ErkJggg==
- Organization: Gdańsk University of Technology, YADE software
We moved YADE to gitlab about a year ago, and I found that the default
merge request merging with a rebase before (clicking the green
"rebase" button) works the best for us.
Especially important to keep all the commits fully compilable and
working. Which fortunately is possible thanks to CI. Then in case of
bugs you can always do git bisect and not worry about code not
compiling.
best regards
Janek
Christoph Hertzberg said: (by the date of Thu, 5 Dec 2019 19:30:30 +0100)
>
> 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
> >>>>>> <joel@xxxxxxxxxxxxxxxxxxx <mailto:joel@xxxxxxxxxxxxxxxxxxx>> 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
> >>>>>> > <gael.guennebaud@xxxxxxxxx <mailto:gael.guennebaud@xxxxxxxxx>
> >>>>>> <mailto:gael.guennebaud@xxxxxxxxx
> >>>>>> <mailto:gael.guennebaud@xxxxxxxxx>>> 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: christoph.hertzberg@xxxxxxx
>
> 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
> -------------------------------------------------------------
>
>
>
--
--
Janek Kozicki, PhD. DSc. Arch. Assoc. Prof.
Gdańsk University of Technology
Faculty of Applied Physics and Mathematics
Department of Theoretical Physics and Quantum Information
--
http://yade-dem.org/
http://pg.edu.pl/jkozicki (click English flag on top right)