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 <hah...@hahnjo.de> 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
