[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: migrating to GitLab
From: |
Jonas Hahnfeld |
Subject: |
Re: migrating to GitLab |
Date: |
Sat, 09 May 2020 20:13:27 +0200 |
User-agent: |
Evolution 3.36.2 |
Am Freitag, den 08.05.2020, 19:10 +0100 schrieb James Lowe:
> On 08/05/2020 12:21, Jonas Hahnfeld wrote:
> > Am Freitag, den 08.05.2020, 13:07 +0200 schrieb David Kastrup:
> > > Jonas Hahnfeld <address@hidden> writes:
> > >
> > > > 3) The idea is to have the "main" repository at GitLab, next to the
> > > > issues and merge requests. This leads to the question what to do with
> > > > Savannah because git is distributed anyway. I first thought about only
> > > > pushing "important" branches and tags to GitLab (master, stable/*,
> > > > release/*). Switching platforms would actually be one of the few
> > > > opportunities to do so - in particular tags are hard to get rid of.
> > > > However most of us are probably going to reuse their local repository,
> > > > just updating the URL. While GitLab has options to prevent pushing
> > > > certain refs, that's probably not a great idea. So I guess I'll just
> > > > push an identical copy to GitLab unless somebody has a better
> > > > proposal.
> > > >
> > > > Ultimately we can talk about cleaning up the Savannah repo and only
> > > > keeping the "important" branches there. This could for example be
> > > > coupled with automated mirroring, which GitLab supports out-of-the-box.
> > > > I won't look into this for the initial switch though, so just make sure
> > > > you're not pushing conflicting commits there...
> > >
> > > What kind of mirroring options are there?
> >
> > Here's the documentation:
> > https://gitlab.com/help/user/project/repository/repository_mirroring.md
> >
> >
> > > I think it makes sense for
> > > the non-developer access to keep referring/pointing to Savannah since I
> > > consider it a resource with more long-term dependable availability.
> >
> > That is exactly the motivation. Syncing master (and a few others) from
> > GitLab to Savannah should satisfy this need.
> >
> > Jonas
>
> As a courtesy many moons ago, I started to cut/paste the commit hash and
> message/title in the issues so that the squad that verified the fixes
> could quickly find them.
After the migration, we can put "Closes #1234" in the commit message
and GitLab will close the related issue once the commit hits master.
> I still do that, is it useful?
still useful for issues closed on SourceForge
> I am assuming that the commit hashes will be mirrored as well or,
> assuming this convention of cutting pasting the commit into the issue is
> still useful when on gitlab.
Yes, the git repo will stay the same, only hosted somewhere else for
development.
So what's the feeling about the migration? go / no-go for tomorrow?
Jonas
signature.asc
Description: This is a digitally signed message part
- migrating to GitLab, Jonas Hahnfeld, 2020/05/08
- Re: migrating to GitLab, Jean-Charles Malahieude, 2020/05/08
- Re: migrating to GitLab, Valentin Villenave, 2020/05/08
- Re: migrating to GitLab, David Kastrup, 2020/05/08
- Re: migrating to GitLab, Jonas Hahnfeld, 2020/05/08
- Re: migrating to GitLab, James Lowe, 2020/05/08
- Re: migrating to GitLab,
Jonas Hahnfeld <=
- Re: migrating to GitLab, Carl Sorensen, 2020/05/09
- Re: migrating to GitLab, David Kastrup, 2020/05/09
- Re: migrating to GitLab, Dan Eble, 2020/05/09
- Re: migrating to GitLab, Jonas Hahnfeld, 2020/05/10
- Re: migrating to GitLab, Han-Wen Nienhuys, 2020/05/10
- Re: migrating to GitLab, Jonas Hahnfeld, 2020/05/10
- Re: migrating to GitLab, David Kastrup, 2020/05/10
- Re: migrating to GitLab, Han-Wen Nienhuys, 2020/05/10
- Re: migrating to GitLab, David Kastrup, 2020/05/10
- Re: migrating to GitLab, David Kastrup, 2020/05/10