lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: migrating to GitLab


From: James Lowe
Subject: Re: migrating to GitLab
Date: Fri, 8 May 2020 19:10:10 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

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.

I still do that, is it useful?

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.

James




reply via email to

[Prev in Thread] Current Thread [Next in Thread]