I fear we have a problem in understanding what the B1900DGVA version is. In my opinion it should not be a branch of the current B1900D master being worked on my Syd A.

B1900DGVA is a much much older version of the current master. This plane was being shared by me in the forum as a temporary gap measure so that people would have a working plane with all the features while Syd gets the master up to that level.

B1900DGVA should never ever inherit from Master. Master will break the working B1900DGVA. The Branch b1900dGVA should never push to the master. Syd is actively changing the way the plane once worked and rightly so, and there for the branch has nothing to add to his working Master.

I believe the B1900DGVA should be it's own master, and then deleted just as soon as Syd''s current version is working correctly in all features.

OR the branch should come from the point when B1900DGVA was the master model of B1900D if that is possible or even makes sense.

The reason you did not see a dif in the last pull request from me is that the change was to a binary PNG file correcting the paint job.

In git, a branch should be understood as a variant of the source code. In our case, of a collection of git repositories holding FG aircraft, this should better translate as "alternative versions" of an aircraft. It may seem counter-intuitive at first, since a branch is going to be typically used for developing new ideas on an aircraft, that will later "merge" into master. Like developing a new paintkit, or a new autopilot, testing new fdms, etc, etc. Once the feature reaches maturity, and its stable, the branch "merges" into master, thus master inheriting these functions.

But in our "aircraft" repos, a branch may serve an additional purpose, (in ADDITION to the classical one). It can encapsulate different versions of an identically-named aircraft. This isolation may be necessary, as an example if two authors have different and excluyent vissions of an aircraft. Or whether an author creates a feature, not accepted by the maintainer of the master work, etc. Thus the branch now will be used as the residence of the "alternative" aircraft.

Here we have 5 variants of this aircraft. All of which are functional, but have different code --some of which will be incompatible/excluyent of other version (master is work by Helijah, and the final status of "master" is his ultimate decision; then we have a version by Sanhozay encapsulated as gshoz, other version by patten, and two versions by the PAF(2), which vary in rembrandt and another code)

Having these different versions of the DC3 encapsulated like this, allow each of this authors to present and develop their own vision of this aircraft, isolated in such manner that either version can be checked, evaluated, tested or flight by any other user, but their changes of code will not necessarily affect other versions. It allow us in FGMEMBERs to create an space for each voice/each vision.

Any branch can be downloaded with the "Download Zip" button on the page. Just check the proper version on the githubAnd then click the "download zip".

If using a git software to check the aircraft, you can use the command "git checkout branch-name" to switch or alternate between branches, effectively changing your version of the Aircraft

If using the FGDATA next with submodules, then the aircraft can be installed into the FGDATA (fgroot) directory, any version tested, and then deinstalled as well if so wished. --This is my favorite way to go

git clone http://git.code.sf.net/p/fgdata/submodules fgdata #clones FGDATA with submodules #needs to indicate the new directory fgdata as the new fgroot (for FG3.5) #a tag release exists to do this for FG3.4 as wellgit submodule init Aircraft/Douglas-Dc3 #initializes the submodule, (like preparing this aircraft for install)git submodule update #updates all initialized submodules, thus actually installing the aircraft. Only install initialized submodules. #Now you have installed the "default" branch of this aircraft, which is master branchcd Aircraft/Douglas-Dc3 #enter the aircraft directory #this directory is effectively identical to the FGMEMBERs repo, and thusgit checkout gshoz #checks gshoz versiongit checkout PAF2 #cehcks PAF2 versioncd ../.. #return to root of the repogit submodule deinit Aircraft/Douglas-Dc3 #this deinstalls your aircraft, and cleans the files off your local copy # you can init/deinit a repo as many times as you want to

If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall

Long answer.The global version of the B190D is an alternative aircraft (older... etc) to the current status of the B190D by Syd Adams. As such it qualifies to be a branch on it.

The major advantage on being a branch is that an user will checkout the branch he/she interests in, and that will completely switch over the code. And thus, if 2 aircraft are incompatible --or different enough-- the end result is perfect. Checking the new branch just completely changes the source code you have, effectively switching one version over other.

What makes the ultimate decision of whether an aircraft belongs to another "new" repo or is a branch instead is the "SpaceName" or the name of the folder it resides. Both, the global version and the current work by SydAdams are named "b1900d", and thus they can't be 2 different repos. They need to exist in the same repo.

One could isolate the global B190D aircraft completely by changing such name-space, but as you mentioned before, this is really a unnecessary work due to the current global VA B190D becoming a legacy in the future

So, it is definitely a branch.

If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall

Never is a strong word. Sometimes a change over master may benefit your globalVA branch. In such case a merge is due. Other tiimes it can break the legacy code, and in such cases it should not merge!

No-one but yourself know the code intimately enough to know if a new change over master is desirable over your branch.

The opposite is also true, but merging into the master branch and thus changing the master work is ultimately a decision currently belonging to Syd Adams.

You could do an amazing contribution to your branch, and thus this contribution could be move over other branches as well.

In the context of two isolated versions of aircraft, to merge or not to merge is a decision that should be evaluated at a per commit case.

In the context of an experimental feature, usually the developed branch just merge completely into master, and then the branch can be eliminated.

If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall

clrCoda wrote in Wed Apr 22, 2015 4:23 am:I believe the B1900DGVA should be it's own master, and then deleted just as soon as Syd''s current version is working correctly in all features.OR the branch should come from the point when B1900DGVA was the master model of B1900D if that is possible or even makes sense.

As explained above, to make the b1900d of global a "master" branch over FGMEMBERs it would require to completely change the "space-name". That requires a significant amount of replacements, and typically one would not do that for a plane to be used only temporally while the "master" work reaches mature state.

In your repo: https://github.com/Raystm2/b1900dyou could actually delete the master, and then rename global VA branch "master". But that would not change the fact that in FGMEMBERs, master still is the art of the current official maintainer, and your work still residing in FGMEMBERs globalVA branch. The simpler way for you to do it, is keep both branches and work and push over the corresponding branch instead, and when sending merge requests, then make sure you are trying to merge in the correct branch as well.

The first pull request of yours, I reverted, because it merged your globalVA branch into FGMEMBERs master, and thus, it was an undesirable change

Delete, in a git repository is something that should be never taken too lightly As opposed, I would say, when the time is right, sending your globalVA version as an annotated tag release, then deleting the branch will do the job. That way, any time in the unforseeable future, we could check again back to the historical version. Then, off course, we can branch the "stable" future master work by SydAdams to create the "next" globalVA version, where you would do your changes, liveries, etc, and have a functioning "future" B190D, as you suggested above, which is clearly possible.

If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall

Once the new commit comes into your globalVA branch at github, then you could go ahead and submit the pull request over FGMEMBERs GlobalVA branch to update globally and bring the changes to the whole community.

Let's walk you thru

************

Step 1: Do your changes

On your local repository (your computer) do any change over the source you need/intend toThis may include changing a PNG, or updating an url, or really -- whatever you need to

This is the most useful git command ever. It tells you exactly where your local repo stands over your origin (remote repo)It is a verbose but really clear output

It will tell you if remote have commits you don't. It will tell you if local have unpushed commits (that remote does not). It will tell you if your local repo has unstaged (unadded files) or uncommitted (modified/deleted) changes.

git commit -m "an explanatory message of what I've done"#This is the most magical of the git commands#it will create a step in your development ladder#you can come back to these steps anytime later#commit frequently, but not too much. What is a sensible change? you decide

Step 5. Publish

You can send 1 commit or N commits to your remote public repoThat effectively publishes the changes to the world.

Here you want to make sure, before publishing that your repo is good, and your changes can go remote. Once go remote, always remote. Never, ever do a history rewrite remotely, unless YOU REALLY REALLY know what you are doing. This include delete all history with "initial commits" type of misdemeanors, if you know what I am talking about

Remote repositories have aliases, for short names. A classical alias is origin. The remote used when "cloning", and where you usually want to pull and push from.

Now publishing is really pulling and then pushing. I advise you get pulling before pushing as your second nature. It will be of great help if working with collaborators. Also keep in mind the branch you are working on, which should be globalVA

Pulls from origin to globalVA bringing new changes up to date. You can avoid the alias and use a full name, and if you ARE in the proper branch you can avoid using the branch name to, so these are sinonimous with previous command

Last edited by IAHM-COL on Wed Apr 22, 2015 5:51 pm, edited 1 time in total.

If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall

If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall

Dear Johan, May I request this whole thread be re-located to the Suport/3rdPartyRepos area that the management kindly created for us?

Best,IH-COL

If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall

Thanks Israel, and I concur with a move I hope Johan will execute. Woudn't even mind if anything I said in this thread that doesn't completely support the positive side of things were removed in all, leaving the helpful information only.

I would not mind language editions eitherI acknowledge that my language limitations make me sound curt sometimes, and I appreciate "edition" when it achieves the same message in a more clear and courteous wayThis thread contain very valuable information for the present and the future users of the Git Hub repositories, and relocating may help a lot to find them with greater ease.

If we gave everybody in the World free software today, but we failed to teach them about the four freedoms, five years from now, would they still have it? Probably not, because if they don’t recognise their freedoms, they’ll let their freedoms fall