Cloning fgdata with GIT submodules

[IAHM-COL]

Lego!?

The "submodules" are obtained via cloning with git an FGDATA next version (3.5 and beyond) with the submodules option. Then initializing and updating the submodules each user intends.

When you do it, you will have a complete $FG_ROOT directory that contains a selected group of aircraft (initialized submodules). This $FG_ROOT is a version 3.5 currently, and although you can change the version file to make it work with any version of 3.x; some aircraft may have incompatible changes with earlier versions of flightgear. Usually not a massive problem. But keep that in mind.

Then, when you launch flightgear, you can set the --fg-root parameter to point to FGDATA with submodules. Don't delete, or copy, or cut, or paste the Aircraft out of there. You will end up altering your local repo, and thus breaking it. A new git cloning may be in order for you before you know it

I hope this helps, but if you are still confused, let me know.
IHCOL

[legoboyvdlp]

Wait, do I replace the jenkins nightly fgdata with the fgdata I download by deleting the 3.5.0 fgdata, then copying the fgdata I download from github to where my old fgdata was? Or what? Sorry, I'm so stupid about this.

Edit: Ah, I clone https://github.com/FGDATA/fgdata/tree/master/Aircraft
Then do git submodule init?

[IAHM-COL]

Hi Lego
You are closer now
Its just you are cloning the github

Readme of github:

Code: Select all

IMPORTANT

This FGDATA was intended as a test to experiment submodules as an strategy to develop Aircraft for flightgear in individual repositories

This TEST FGDATA will no longer be updated.

An official FGDATA repository without Aircraft is located at: https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/

A fork of the official FGDATA repository with Aircraft added as submodules, derived from this test is now hosted at: https://sourceforge.net/p/fgdata/submodules/ci/next/tree/


That tell you that FGDATA in github applies no more. Use the one in Sourceforge instead.

Code: Select all

git clone http://git.code.sf.net/p/fgdata/submodules fgdata-submodules


That will be your FGROOT, so yes, you replace the jenkins nightly build with that one.
(do not clone the "official" one because that one does not have the submodules that allows you to restore your planes back into FGDATA as submodules)

then, inside the FGDATA with submodules root directory that the clone step above creates, do

Code: Select all

git submodule init Aircraft/707
git submodule update


That above only adds the code for 707. Not other aircraft is fetched!
you can initialize as many aircrafts as you want before updating. There is not limit into how many aircrafts you initialize actually. And initializing is "priming" your git repo to update these aircraft only. Example, you wont be updating any other of the almost 600 aircrafts that way

You can also, if you wish to, get ALL submodules installed.
This is the "complete FGDATA with submodules" version

Code: Select all

git submodule init
git submodule update


That way you will be updating your FGDATA to have all the aircrafts currently available. Your initial update may take a while ... but if you want all aircraft, it is the easier way to go

Best,
Israel

[legoboyvdlp]

Thanks!

And btw I just run that code again to update my aircrafts?

And to update fgdata I git pull. And to update fgfs.exe I do a Jenks. Simple, right?

[IAHM-COL]

yes. you got it.
to update your aircraft you do, in fgdata with submodules

Code: Select all

git pull
git submodule update


You need to git pull first, to update your FGDATA. FGDATA is the one that tracks if a submodule needs update or not.

The fgfs, as you said, you can use jenkins to update it. (that will be the "flightgear" repo)

Simple. Right.

[IAHM-COL]

New Aircraft added as submodule!

Hi all

We have the Fictional but very very sleek Piper archer ready for initialization and testing
viewtopic.php?f=4&t=23962

Code: Select all

Aircraft/piper-archer


Enjoy!

IHCOL

[hamzaalloush]

IAHM-COL, i'm not sure how git works, but can we fork/branch off submodules and work on it for our own good? or is this not allowed as this isn't a development repo as you said.

[IAHM-COL]

In git anyone can branch, fork, do you own modifications etc etc
As a matter of fact you can pull requests to the git with submodules as well:

New Aircrafts, as a good example.

Keep in mind that modifications to the FGDATA need to be made in the original FGDATA instead.
the submodules sit downstream, meaning those changes come from the Official one.
Not merging commits back to FGDATA limits accesibility to other "non-submodules" FG users, and thus I discourage that.

But when permitent to aircraft submodules, you can definitely fork

Best,
IHCOL

[Hooray]

that is exactly what most long-term contributors are concerned about - obviously, it is possible technically - but not necessarily the smartest idea, given how most aircraft development is stagnating anyway, and because there are hardly any volunteers available to help review/integrate and merge/commit such changes. Honestly, it does make sense to get in touch with the corresponding people, or if the aircraft is generally unmaintained currently - just get in touch via the devel list to become the maintainer for the corresponding aircraft.

[IAHM-COL]

As a matter of fact, Flying Solo

Each Aircraft repo is a "development repo" on its own right

Fork any one of them, and development at your leisure
Then submit pull requests for considering

Keep in mind, only, for what Hooray says that we are an unofficial divergent repository. and your changes may never become official as of now.
Available via FGMEMBERs and the future FGMEMBERs catalog to the whole FG comunity

So yes

Aircraft development
Totally invited, welcomed, and encouraged.

Go ahead.
Run (fly) free

IHCOL

[wlbragg]

It may be stagnant for a reason.

I see aircraft developers that have long since backed off the official bandwagon joining in on the new fgmembers distribution, WHY?

I think our community needs to reexamine our politics and strive for openness and inclusion.

I'm just a user like anyone else and I am thrilled to death with fgmembers because it IS being managed and is making every attempt to be inclusionary. It has brought out into the light tons of modified aircraft that are not being added to the "official" repo for whatever arbitrary reason.

Especially now that it is divergent of fgdata, it should be wide open with little to no over site as to what can or can't be included, within reason.

[karam]

that is exactly what most long-term contributors are concerned about - obviously, it is possible technically - but not necessarily the smartest idea, given how most aircraft development is stagnating anyway, and because there are hardly any volunteers available to help review/integrate and merge/commit such changes. Honestly, it does make sense to get in touch with the corresponding people, or if the aircraft is generally unmaintained currently - just get in touch via the devel list to become the maintainer for the corresponding aircraft.

Having each aircraft in a separate git repository may help to resolve the problem of attracting volunteers and pick up new maintainers of abandoned aircraft. New contributors will be able to fork an aircraft, work on it, make a pull request to the "official"/master repository. The request may or may not be accepted. If there is no maintainer for the aircraft the pull request will probably be ignored. The new developer continue to work on the aircraft in his own fork and if skilled the developer will prove his worth as a potential new maintainer and his fork can become the master repository. On the other hand if the new developer turns out to be less skilled his work can simply be ignored.

The non-developers of FG, aka users, does not have to know anything about all the repositories and forks. That is the FG release maintainers headache who will compile each new official release of FG. But having the alternatives will give power users a chance to test a lot of aircraft.

Do the complaining in this thread, and in the dev mailing list, come from a perceived feeling of threat - if a maintainer ignores important contributions to "his" aircraft he might be overrun by other developers. A "competing" developer may become the preferred developer and his fork is the aircraft users actually fly. However, I think this scenario is unlikely to happen since most developers wants to contribute rather than seek conflicts. Remember, a hostile takeover is trivial even with the current FGADDON model since it is easy to checkout an aircraft and simply upload it to another repository and hack away. IAHM-COLs work here does not change that and I think it actually counters the threat of hostile takeovers and paves a way to attract more contributors.

[hamzaalloush]

that is exactly what most long-term contributors are concerned about - obviously, it is possible technically - but not necessarily the smartest idea, given how most aircraft development is stagnating anyway, and because there are hardly any volunteers available to help review/integrate and merge/commit such changes. Honestly, it does make sense to get in touch with the corresponding people, or if the aircraft is generally unmaintained currently - just get in touch via the devel list to become the maintainer for the corresponding aircraft.

Hooray, i always appreciate what you say, and i know that you always looks at the big picture for FG as a whole, ideally each aircraft will have a maintainer which is what you are refering. but the world is not perfect.

i simply shouldn't ask for approval to fork an aircraft on a maillist, which is GPL anyway.

IAHM-COL's method makes it much simpler for me.

and it needs not be merged into the original aircraft/submodule, simple refusal of the author and it's added to FGMEMBERS as my own.

[IAHM-COL]

Hooray, i always appreciate what you say, and i know that you always looks at the big picture for FG as a whole, ideally each aircraft will have a maintainer which is what you are refering. but the world is not perfect. ... ETC

Ditto

Besides, if your contribution is great, well...
We need not to be stubborn and get the goods.

Also, in git, when one merges, one can actually take the right, drop the wrong.
Is a per-case scenery situation.

So an user contribution can be line-by-line accepted or refused.

IH-COL

[legoboyvdlp]

By the way, would it be possible for scenery to be done? Like the EDDF, EGOD, which many download? And other customs.