Re: Issues updating planes located in FGAddon

> I’d prefer we get some tooling in place to allow at least
search-and-replace operations across the whole set, working on eg
instrument changes or AP changes without that would be more error-prone.

If we need to do that, we did something wrong, and we are doing it wrong
since the beginning - instruments / APs / etc. should not be copied into
every aircraft but at the very least be in a separate repository integrated
into the aircraft as a git submodule, or even better we have a framework
that allows integration of instruments etc. from a repository like FGAddon.

Am Di., 2. Juni 2026 um 18:58 Uhr schrieb James Turner <[email protected]
>:

>
>
> On 1 Jun 2026, at 23:00, Josh Davidson <[email protected]>
> wrote:
>
> How about a git organization with planes as sub-repos? That shouldn't be a
> problem at all. (Suggested to me by a private email)
>
>
> That is possible but needs (I think) the following:
>  - get permission from GitLab (formally, eg in writing) that a group/org
> with 200+ repos is valid use of their SaaS service, and they won’t consider
> it abuse.
>  - apply for an open-source org (like we do for Flightgear already) for
> that group (I could help with that, but we need to show that every repo is
> license compatible, and do some other house-keeping)
>  - have scripts that extract aircraft from the svn history and create
> corresponding projects/repos **with Git LFS enabled**.
>
> (The LFS part is really important, to make the checkout experience ok)
>
> And having done that, we would have 200+ discrete repos: so no way to grep
> / modify multiple aircraft at once. I’d prefer we get some tooling in place
> to allow at least search-and-replace operations across the whole set,
> working on eg instrument changes or AP changes without that would be more
> error-prone.
>
> What we can’t do is make them all submodules of one super-repo, I think
> that will be just as slow / bad to checkout as the current SVN, or close to
> it. (My experience is more than 10+ submodules is asking for trouble)
>
> However, if we do that, there is no reason to have a GitLab repo for eg
> the A320 or C172, since we’re just mirroring a repo that exists elsewhere
> (on GitHub or anywhere else); I think we may as well have the Fgaddon
> catalog builder just pull from the primary repo for each aircraft.
>
> There’s also the user education part of this, we’re changing the workflow
> and tooling for a bunch of people, many of whom are not ‘coders’. Concepts
> like push-ing and rebasing are going to need some hand-holding for them, I
> expect, and the state of Windows GUI git-clients is a bit tricky, to put it
> mildly.
>
> I’d be curious to hear from Torsten D, who did the private negotiations
> with SF originally to be allowed the current SVN setup, if the above seems
> feasible, since this is all just based on my experience.
>
> Kind regards,
> James
>
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel