Board index FlightGear Support 3rd Party Repositories

Problem at the old Git Hub regarding b1900dGVA versio

Problem at the old Git Hub regarding b1900dGVA versio

Postby clrCoda » Wed Apr 22, 2015 5:23 am

Dear Israel,

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.

-- Take good care -- Ray
Ray St. Marie
clrCoda
 
Posts: 1225
Joined: Wed Apr 07, 2010 12:04 pm

Re: Problem at the old Git Hub regarding b1900dGVA versio

Postby IAHM-COL » Wed Apr 22, 2015 4:09 pm

Dear Ray.

Few things:
1. Branches and alternative aircraft versions

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.

Let's evaluate our highly versioned aircraft: The Douglas-dc3

https://github.com/FGMEMBERS/Douglas-Dc3

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)

https://github.com/FGMEMBERS/Douglas-Dc3/branches

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 github
Image
And 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

Code: Select all
git clone https://github.com/FGMEMBERS/Douglas-Dc3.git  #clones the repo
git checkout gshoz #changes to gshoz version
git checkout PAF  #changes to PAF (version1)
git checkout master #returns to master


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

Code: Select all
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 well
git 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 branch
cd Aircraft/Douglas-Dc3   #enter the aircraft directory
    #this directory is effectively identical to the FGMEMBERs repo, and thus
git checkout gshoz  #checks gshoz version
git checkout PAF2   #cehcks PAF2 version
cd ../..   #return to root of the repo
git 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
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Problem at the old Git Hub regarding b1900dGVA versio

Postby IAHM-COL » Wed Apr 22, 2015 4:15 pm

2. B1900D Global: To be or not to be (a branch?)

Brief answer. Yes. It is a branch.

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
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Problem at the old Git Hub regarding b1900dGVA versio

Postby IAHM-COL » Wed Apr 22, 2015 4:19 pm

To merge or not merge?

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
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Problem at the old Git Hub regarding b1900dGVA versio

Postby IAHM-COL » Wed Apr 22, 2015 4:24 pm

clrCoda wrote in Wed Apr 22, 2015 5: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/b1900d
you 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 :oops:

Delete, in a git repository is something that should be never taken too lightly :D
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
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Problem at the old Git Hub regarding b1900dGVA versio

Postby IAHM-COL » Wed Apr 22, 2015 4:46 pm

clrCoda wrote in Wed Apr 22, 2015 5:23 am: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.

-- Take good care -- Ray



The reason I do not see a diff is because you had not completed the submission of your changes, whatever these may be.
(maybe you had not commited? or pushed?)

I know this as a fact, because I can see all commits pushed over your repo on any branch here:

Master: https://github.com/Raystm2/b1900d/commits/master
global: https://github.com/Raystm2/b1900d/commits/globalVA

And I can see there are no new commits with any change over any PNG occuring

Did you

Code: Select all
git add .
git commit -m "message"
git push origin globalVA


over your local computer repo, after making changes?

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 to
This may include changing a PNG, or updating an url, or really -- whatever you need to

Step 2: Verify your changes

Code: Select all
git status


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.

Step 3. Add

Code: Select all
git add --all
#or git add .  #there is a period at the end


Will add unstaged files, you can verify with git status again :)

Step 4. Commit

Code: Select all
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 repo
That 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.

you can check with

Code: Select all
git remote -v


Tipically a very verbose answer will tell you that remote origin is, in your case, example

"origin git@github.com:Raystm2/b1900d.git [push and pull]"

Meaning that is the repo aliased origin, and you push and pull to it

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

Code: Select all
git branch


Should respond

* globalVA

Then,

Code: Select all
git pull origin 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

Code: Select all
git pull git@github.com:Raystm2/b1900d.git globalVA
git pull git@github.com:Raystm2/b1900d.git
git pull


By default git pull will pull from origin into the brach you are at, at the moment, making for the shortest most effective command

After pulling, publish

To publish, you use the similar command git push (it works just as pull, but in the other direction!, instead of copying from remote to local, it copies from local to remote)

Code: Select all
git push origin globalVA


identical to saying
Code: Select all
git push git@github.com:Raystm2/b1900d.git globalVA


(push defaults to master, so in your case always specify which branch you are writing to the remote!)

That is

Code: Select all
git push


Always means

Code: Select all
git push origin master



I hope it helps ;)

IH-COL
Last edited by IAHM-COL on Wed Apr 22, 2015 6: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
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Problem at the old Git Hub regarding b1900dGVA versio

Postby IAHM-COL » Wed Apr 22, 2015 4:47 pm

A final word

Once you commit, I should be able to see a diff, even if you only changed 1 PNG file

Example:

https://github.com/IAHM-COL/727-230/com ... dc283a79c2
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
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Problem at the old Git Hub regarding b1900dGVA versio

Postby IAHM-COL » Fri May 01, 2015 1:48 am

@Johan

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
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux

Re: Problem at the old Git Hub regarding b1900dGVA versio

Postby clrCoda » Fri May 01, 2015 1:52 am

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.

--Ray
Ray St. Marie
clrCoda
 
Posts: 1225
Joined: Wed Apr 07, 2010 12:04 pm

Re: Problem at the old Git Hub regarding b1900dGVA versio

Postby IAHM-COL » Fri May 01, 2015 1:59 am

I would not mind language editions either
I 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 way
This 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
User avatar
IAHM-COL
Retired
 
Posts: 4057
Joined: Wed Aug 08, 2012 6:40 pm
Location: Homey, NV (KXTA) - U.S.A
Callsign: HK-424D or ICAO4243
Version: 3.7-git
OS: Linux


Return to 3rd Party Repositories

Who is online

Users browsing this forum: No registered users and 2 guests