Re: migrating to GitLab

[Jonas Hahnfeld]

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