FGData Merge Request #316: Bug fixes, rename .ac object Screen to Screen1, add offset's (rejected)

The FG1000 GDU1045.1 PFD has an object named incorrectly Screen should be Screen1. It is also missing keybinding offsets for many of the keys.

[Wayne Bragg]

Well, this is why I don't like to do merge request in SorceForge I don't know how or when I added these last three commits to this fork. Didn't know they were even a part of this fork. They are not what I wanted included in in this merge request. So I will reject it and try it again with the fg1000 changes only.

[Wayne Bragg]

So how do I reset this fork to the current fgdata next branch. I don't think I should have to do a new fork to get a clean branch?

[Florent Rougon]

Use git status, git log --format=oneline and git branch to see where you are. Show us the results.

In order not to have the problems I assume you had (based on your first message), you need to push commits that come immediately after (in terms of parent-child relations) the HEAD of the official (public) FGData branch you want to merge your changes into.

HTH

[Wayne Bragg]

D:\fg stuff\wlbragg-fgdata>git status
On branch fg1000
Your branch is ahead of 'origin/next' by 1 commit.
(use "git push" to publish your local commits)

nothing to commit, working tree clean

D:\fg stuff\wlbragg-fgdata>git log --format=oneline
2d82401bfe72e13c1020fb84d94ce9fe87a54bb9 (HEAD -> fg1000, wlbragg/fg1000) Bug fixes, rename .ac object Screen to Screen1, add offset's
c42fe5c0e1e5c3622bb7a2ee99b3f41e8a0a5909 (origin/next, origin/HEAD, next, clean) C-47 AI aircraft
f8d46dea5e7db8539c0ccd548db6d045b974d463 Flightplan requires crossat, alt no longer works
2168e49a49be5090491e96b992a8f7032c913d42 Limit ice to northern and southern regions
08dd802845a4af2b557f98e016745fca95e3271b Restore inland water ice option
37a1804ad60fba95f18551aa81687b572a3e70ba Corendon Traffic update
eda516e1b8df61e0f4e0d16971ac6da194afd38e Update of Spanish translation files
16d96b3b176fa479a8a95028b5e4867b85675258 gui/dialogs/flight-recorder.xml: various improvements.
eee11c00b00f4869a7c763fceb4f6d1a95abd657 Translations/default/options.xml: document load-tape-create-video and load-tape-fixed-dt.
b055deeb903428742638cfbaa807a9e537f3c149 gui/dialogs/flight-recorder-load.xml: added support for create-video and fixed-dt.
3699884297fa4521139b80e491fc6f824ca51ae5 gui/dialogs/time-mode.xml: added control of fixed-dt.
0395b916c9e39fe0be298cb7e8f02afe536b0ca1 defaults.xml: added sim/replay/record-continuous-compression
f2a724adcbe0b5e43137cb114fbf124c94e289cf defaults.xml: added sim/time/simple-time/enabled.
05f7b034d01be57920f235cfb9f43a040e2386f0 Added user interface for video encoding.
483a0dda075acb4c608dd3100bdea3c3432eb522 i18n: refresh the FlightGear-nonQt.xlf files
1b0e2147adbd3344128e25925f4f5df447c2fc6a i18n: add splash screen translatable strings
96ca6e6a4d810bde1285ee1e26d187cf7d5cd3bd Update Polish translation
5affbac384acd32a72e70c98acc8000dbf90a30a Update of Qt translation files for all languages
6b4d88e01ef3386c85fb46ac7f8990af91e7bea8 Fix not working multi-key commands.
650ec1ce707715d6fb5da1c69f1dbc62bc3686ed Delete obsolete multi-key weather scenarios and replace them with the current ones.
889d0cb915e577b6656d3c4f253110e3dcefe137 Fix Softkey 10, 11 and 12 for FG1000 multi-keys
eaf03b600525f1dd1c451a3199303a893f88b855 Add object shadows to water
97ea17ea4fb079a9d20f575cdecb9da4c33b4aa3 Fix to overlays issue 2648
dcf8641329db271634ed3f590140fc5330a10744 WS30: Full ALS Detailed and Ultra implementation
18905022830cc66da564a8be4cdc9c70ea08317f Add argument validation in canvas_efis/eicas-message-sys.nas
28e865f1e6fd1530ba60c621d13864130c57be3b Bugfix for aircraft.nas: declare missing member variable
d4bd49f5f97521d36d4b352708cc4c3441c19af0 WS30: Multi-texture support, global coordinates
f0d29c347ea7710705ea7a6990502b00d66b14f6 Set the dialog "Metar description" larger for more convenient use
f5a5ba60ca01ab0bedcd5d83f637237206093716 Fix Equipment-Instrument Settings inconsistency toward Altimeter Indicator.
7b13c2da25104268314215477ceb3c57a9360b1f Update of Spanish translation files
688bbbc167284a495012a962661a853337a14075 WS30: Add zUpTransform and modelOffset, fix snow
e0fb796badb23134a3553b2931487d3d353dc115 Corrections for Polish translation
dbbd89a05b5ccc47d663c9ee1163b8ffbf4dc2ea Add missing --igc protocol option displayed in help
d723b0b518312f5b2d11e3004046fd8840a40122 WS30 - Uniform Arrays and lighting model
6b943c5e5c9ea10cbb9b321f8a16b73631826237 WS30: Photoscenery shaders
fb6da32cecdfc06c217d067d897e86aec095971f Fix in code definition of hpa.
7a7b875b5889c7c85efd4344a20f478745722c8b Fix hpa displayed values at KAP140
84c45c2bd6e73b8ce95e01a7be137236113e952c Traffic and Liveries update for Royal Air Maroc
64e5abda41c615fadcda975c5677b539eca041c7 WS30 shaders:
851f47f576ea03a6bcf9419ad1c2ba49a07c3575 WS30: Fix errors on AMD
ffe873806511decbde35ba0a86343425528fc8ca WS30: Correct phototexture coordinates
f53283be1251e0e14dd5d0ab34d9dd7140ebe8bc WS30: Correct orthophoto texture coordinates
b043981992373d2ff95d58e99e70fa3adc3716dd WS30: Initial photoscenery effect
78df0cb68c56914494876915f6fcead3bdedf976 WS30 shaders:
06b3fe62e575d26cb3297903a6653f0be894dbbc gui/dialogs/flight-recorder.xml: improved layout a little.
aaa6c3ff420097cd88fd9553881968ac96a6adac WS30: Fix merge markers.
e5123eeb461c501af0b02b5e2da091c3e43e740f WS30 : terrain shaders from vs
bf55997a56ae175691c13897954723a255a08011 WS30: Improved ambient color
baba195a361a3fd45244b8aaa2fe8d13c78517ef Updated Traffic for Tunisair Group
e9fda0dbbc62c05645954a4b8ad123c33e21d955 keyboard.xml: remove duplicate commands (fix by Benedikt Hallinger)
414c7c47705f0964b26176320d6c7400a8bf5d26 Update "nonQt" files for all languages
c905e5e5c0f69404378250909831a6f56746f817 Update the list of options displayed for -h -v
c0e667225f0b501f1d4a8b489201c138b2e485d5 Updated Traffic for Transavia NL and Transavia France
51730bd8bfe802c6f133f8740ffe405c0b278b43 Updated Traffic for AeroMexico and AeroMexicoConnect
ed4e88a6a9a7ace27c7812bcc2988426a97be73d Updated Traffic and Liveries for Eastern Airways UK
63487bbe7b046566f3320f3e569c06eae72930d2 WS30 ultra shader - port ambient lighting fix
c81870cff1bcaf844bd08253aeac8eddaf3f7c59 Added 'Time mode' dialogue to File menu.
fc42ef3fe4b7f08059878709ac930916005389b8 WS30: Include ambient light in ALS fragment shader
0bce3c966f13f32d091cfabae1774df6120c885b WS30: landclass and texture lookups in fragment shader
38dc00faf12594d6980f85993c45c387184be1fd WS30 - Set Effects for ws30Roads etc.
0dcbfdbf53d17ead14be5e9342fcfc1a1ea520a6 docs: XML sound changes
b5b9568bc7746199426acba80b633eb40e9d9126 Local weather: change unknown landcover message to use logprint
dc697141b8355107acab099c38e2b6bce3630b79 Tyre effects (spray, smoke) rework
9549655c2e8ffa89ce075e9b0efa247421f6a6e5 AI: added fallback model for 777 (instead of AF 777)
dda3fdbc7d743a685cbf5b019f86731270f92a89 Updated Traffic for Blue Air

D:\fg stuff\wlbragg-fgdata>git branch
clean
* fg1000
next
volcanos

D:\fg stuff\wlbragg-fgdata>

I think I might understand this a bit better just by executing the commands you gave me. What I think I need is to pull a new clean branch and then add my fg1000 changes to that branch and to the merge request off of it? How would I make or pull a new clean branch?

[Florent Rougon]

Yes, your last paragraph makes sense, I'll give commands below; however, since this all depends on the current state of your repo, there is a sheer number of “if”s.

If you look at your MR, you should see that none of the commits-to-be-merged are in official FGData (otherwise they wouldn't be shown here) and that the parent of the oldest of these (in parent-child order) is:

37a1804ad60fba95f18551aa81687b572a3e70ba Corendon Traffic update

The beginning of your git log --format=oneline output shows this commit and, reading upwards, all its descendants up to the tip of the branch you asked SF to merge in. So, in order to fulfill your request, SF would do a merge commit containing all this stuff so as to graft your changes onto what is present in official FGData. And this is not desirable. Normally, this shouldn't happen if you followed the procedure at:

https://wiki.flightgear.org/Making_a_SourceForge_Merge_Request

So, I'll answer your question but it would be much easier for everyone if you followed the wiki page.

I assume you want to merge only the latest commit of this MR, i.e. 2d82401bfe.

First create a branch out of official FGData next:

git checkout -b new-branch-name xxx

Here, xxx must be replaced with a ref (a branch name, a commit id are refs) that corresponds to the latest commit in official FGData next. The name is repo-dependent in general, because Git lets you create, rename and commit to local branches, for one. In your case, it is unfortunately neither next nor origin/next, because your git log --format=oneline output shows that these point to c42fe5c0e1 which is not in official FGData next at all. You presumably committed and pushed work of yours to a next branch (local next + origin/next, where the latter presumably refers to your personal fork at SF), and this naturally leads to confusion. That is why the wiki page makes you create a “feature branch” with a different name.

Then, assuming you did the above, a simple git cherry-pick 2d82401bfe would do—as long as there is no conflict between 2d82401bfe and what's in official FGData next.

So, the first problem you have now is to get a branch with clean FGData next contents and nothing else. The second problem is that you committed local changes to your local next branch, and this is certainly going to be confusing. You could easily reset it to official next, however I don't know if you're ready to lose the changes present there—probably not.

Do you want to keep all commits in your current next branch (hoping to merge some or all of them later, for instance)? If so, I think the easiest route (short of starting over) is to rename your next branch to some other name, for instance:

git branch -m next tmp-work

Then you can create a new local next branch from 37a1804a in order to later update it:

git checkout -b next 37a1804a

In order to update it, we need a remote that points to the official FGData repo. To avoid confusion, I'd prefer this to be the origin remote, however I suspect your current origin points to your personal fork at SF. Please confirm this using git remote -v.

Please also paste the commands you ran so I know where we are (unless of course you prefer to start over).

[Wayne Bragg]

Thank you so much. I think I finally understand a few crucial concepts of the fork concept. All I really needed was the information on how to get a new clean/current fgdata next branch (origin) into my fork. From there, I think I have enough knowledge to manage this. My whole problem was from not understanding, at my skill level, I need to keep a clean, current, origin/next branch that I can continually update to the current fgdata next. Then when I need to make a merge request, branch from it, make my changes and request a merge. As far as following the instruction at the link you provided, I did read that, more than once over time, including recently. But I think I was well beyond those opening steps. I wasn't understanding the relationship of my fork and the branches in it to the main fgdata branch on FG SourceForge.
Thank you for taking the time to explain Florent, I understand exactly where to go from here. I don't think I need to re-submit this particular merge request. It sounded like Stuart would prefer to just make the few minor edits to fg1000 himself. But I have some volcano work and volcano cloud lighting I want to submit at some point. Thanks again for your time.

[Florent Rougon]

Hi Wayne,

Glad to hear it helped. Yes, the key to avoid problems here is to have “what you want to merge” be one or more commits that are direct descendants of the current tip of the upstream branch you want to merge your changes into (so, if you do git log -p in the local branch to merge, you should first see the-changes-you-want-to-merge-and-nothing-more, followed by the latest commit in the official branch).

Since the “current tip of the upstream branch” might change while you are preparing all this , using git pull --rebase immediately before submitting the MR is a good idea—as shown in the aforementioned wiki page .

Using git pull --rebase requires that Git know that the local branch tracks some remote branch as upstream, otherwise it wouldn't know where to pull changes from. Depending on how the local branch was created, there may be nothing to do for this, or a command like git branch --set-upstream-to=origin/next where origin is a remote that points to the official repository (the remote name doesn't matter for Git, but the remote must point to the official repo for the use case discussed here).

Note: there was a copy/paste error (incorrect commit id) in my previous message: it was in the paragraph that mentions the git cherry-pick command, and is now fixed. The commit to cherry-pick is the one we want to merge, of course. Sorry if this was confusing.

[Wayne Bragg]

To verify, this is what my fork should look like. Yes, my origin was git.code.sf.net/u/wlbragg/fgdata

D:\fg stuff\wlbragg-fgdata>git remote -v
origin https://git.code.sf.net/p/flightgear/fgdata (fetch)
origin https://git.code.sf.net/p/flightgear/fgdata (push)
wlbragg https://wlbragg@git.code.sf.net/u/wlbragg/fgdata (fetch)
wlbragg https://wlbragg@git.code.sf.net/u/wlbragg/fgdata (push)

Thanks again.

[Florent Rougon]

Yes, this looks good. I believe I've never pushed any Git commit using https, however according to the SourceForge docs, it should be possible—albeit slower than over SSH. So, in my case, the fetch and push URL for my FGData fork is:

ssh://frougon@git.code.sf.net/u/frougon/flightgear-fgdata

(flightgear-fgdata is the name I chose for my FGData fork using the SF interface.)

I think it should be possible to push over SSH even under Windows, but if it works for you using https, no problem.

(About 20 years ago, I used the PuTTY SSH client under Windows, and it also had a pageant.exe executable which works similarly as ssh-agent, i.e. it can keep one or more SSH keys in memory within a “session”, so as to avoid the need to enter the same passphrase every time when doing many connections that can be authenticated with the same SSH key. If you're not used to this and only push a commit once in a while, this is probably overkill.)

[Florent Rougon]

So, with these remotes in place, assuming you've already done these:

git branch -m next tmp-work      # rename local next to tmp-work
git checkout -b next 37a1804a    # start from an official commit

then getting a clean, up-to-date next should be as simple as (I hope!):

git status                       # make sure you are on next
git branch --set-upstream-to=origin/next
git pull

Just check with git log once this is done.