# x64 Development

#### jangofett287

##### Heat shield 'tester'
For what it's worth, I've generally found GitKraken to be the least worst GUI for git.

That works fine as long as that repository is only used by one person
Once "the source" (I think 'upstream' is the right term) of that copy is changed by another developer things get complicated in my head.
Another level of abstraction is the "fork" (github thing)...
So 1st I make a fork of martins repository - easy, one click,
Then I 'clone' (possibly wrong lingo) a local copy from my github repository...
while developing I like to "update" (possibly wrong lingo) my local copy with changes martin has made in the "original" repository...
That's where the 'remote' and 'upstream' things get confusing at first.

I would love to have a thread (single post) that would describe these steps for contributing to Orbiter[*].

[*] "How to provide a pull request to Orbiter"

I'll try and explain:
"remote" is just a git server with a copy of the repo.
"fork" is GitHub's term for a copy of an existing repo on to a different account. This makes a new repo. GitHub keeps note of the connection and makes it visible in the "network" tab and also when creating pull requests.
"clone" is making a copy of a repo on your local machine
"origin" is usually the remote you cloned from
"upstream" is usually the remote you forked from. You may have to add this manually.

The recommended workflow is fork, clone, branch, commit, push (to origin, ie: your fork), pull request.

#### martins

##### Orbiter Founder
Orbiter Founder
Speaking of git hell, I may just have run into a slight snag.
I renamed my trunk branch from master to main to comply with current github convention.
(If you have cloned the repository you may need to update your local repository accordingly, but you will get a warning from github on your next pull with instructions).

However, I wonder if there are some unpleasant side effects with respect to other github forks. I was just trying to merge Face's pull request, but the CI build failed. It looks like the merge doesn't just try to update the two files in the pull request, but changes a lot of other files, essentially reverting my 64-bit edits. I wonder if the branch name change got things out of sync (despite github claiming that it should be transparent).

@Face : sorry to be a pain, but just to check if that is the problem: could you update your local repository to reflect the name change and then push it to your gitub repo. I'll then try to merge again. If that also doesn't work I'll apply the changes manually, and hope that things will sync again in future pull requests.

Edit: never mind, I fixed my problem by first merging the pull request into a separate branch, and then merging into main from there.

Last edited:

#### GLS

##### Well-known member
Orbiter Contributor
Well, the point is: git is not easy. Far from it. It is THE most complex and unnecessarily complicated tool of all the DVCS systems that came out around 2005. And I agree: Github is not making the situation any better.
I knew the git part. I just created a Github account and... yeah, "not making the situation any better" is an understatement.

ATM, my opinion of this is such that I'll probably not move my SSV repo to there. The best part (<- irony) is where they show in the user homepage everything the user does... probably somewhere in there is also the last time the user went to the bathroom.

#### Urwumpe

##### Not funny anymore
Donator
Well, the point is: git is not easy. Far from it. It is THE most complex and unnecessarily complicated tool of all the DVCS systems that came out around 2005. And I agree: Github is not making the situation any better.

I would mildly disagree there:

• It is complex, but not the most complex (That is TFVC - also from 2005, BTW).
• It is complex, but not unnecessarily. The sophistication of the tool serves a purpose, sometimes sadly an historic one.
But yeah, it isn't easy, like any distributed system. If it would be, I would have one job less. But it can be done and even beginners can learn quickly how to use it - even on the command line. Or maybe especially on the command line. Teaching old subversion users, that its really better to commit things, even if they might be wrong, is the hardest work. A commit on git is done in less than a second for a big project. On subversion, this was often the time for doing your weekend shopping, while your computer was busy.

And of course, learning to use git is not the same as learning to use Github. While I understand this fork-thing from a business perspective of them, its not a part of git , it just adds an additional layer into the repository tree, a new layer of complexity.

#### n72.75

Tutorial Publisher
Donator
I really like git. Github is definitely its own flavor though.

The way we approach it with NASSP:

There is a branch on the orbiternassp account called Orbiter2016 (orbiternassp/Orbiter2016 ). This is what we push new features/fixes to when an update comes out.

Each developer has their own fork. On our own forks we have the Orbiter2016 branch (I know these release target R90, it's just a name), as well as as many other branches as we like. Here is an example of mine: https://github.com/n7275/NASSP/branches. I keep my Orbiter2016 branch even with the orbiternassp/Orbiter2016 so that if I need to test another users scenario on the current build, or just fly a mission, all I have to do is check out my Orbiter2016 branch. Github even has a feature now that let's you fetch and merge from the upstream branch (for our purposes, the repo you forked from).

The big advantage with git is that I can also checkout other developer's branches, and I can even make commits and pull requests to their repositories and branches as well (they have to pull my changes hence I make a pull "request" in github lingo, and they "approve the request").

Most of the committing and pushing of code I do within visual studio.

VS/git also has its own diff viewer for each commit, that you can use before you commit.

Some times, like in the case of my fuel cell project this ran for many months and, while I made commits and added features to it I also pulled changes from the main repo so that could avoid, or at lease immediately address merge conflicts.

If you really mess your "main" branch up, you can always checkout main, fetch upstream, and reset --hard. This will force your "main" branch to be exactly the same as the upstream's.

I really recommend the workflow of: If you want to implement a new feature, work on it in a branch of your fork. When it's done and you've tested it, make a pull request from:

orbitersim/orbiter <--- yourUser/myNewFeatureBranchThatIveTestedRealGoodAndHasNoBugsThatIKnowOf

#### jedidia

##### shoemaker without legs
There is no easy way around that, recipes don't work in my experience. You can't teach people to fly a plane by handing them the checklist, either.
The thing is, contributing to an existing project is more complicated than managing your own repo... The basic workflow with git is pretty simple. Pretty much all you need working in your own repo is pull, commit, push, and the occasional stash and merge.
When you're contributing to a project with lots of other contributers... yeah things can get messsy pretty quickly. You have to at least learn about rebase, pull requests and resolving merge conflicts. And while an IDE can make the later one a lot less painful, I have no idea how VisualStudio express performs in that regard...

#### Urwumpe

##### Not funny anymore
Donator
The thing is, contributing to an existing project is more complicated than managing your own repo... The basic workflow with git is pretty simple. Pretty much all you need working in your own repo is pull, commit, push, and the occasional stash and merge.
When you're contributing to a project with lots of other contributers... yeah things can get messsy pretty quickly. You have to at least learn about rebase, pull requests and resolving merge conflicts. And while an IDE can make the later one a lot less painful, I have no idea how VisualStudio express performs in that regard...

Well, I think you can ignore the rebase. It is not needed for the actual workflow at all, it only helps making the version history easier to read. And merges are way easier in git than in Subversion or Mercurial. And don't get me started on old CVS there.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
The thing is, contributing to an existing project is more complicated than managing your own repo... The basic workflow with git is pretty simple. Pretty much all you need working in your own repo is pull, commit, push, and the occasional stash and merge.
When you're contributing to a project with lots of other contributers... yeah things can get messsy pretty quickly. You have to at least learn about rebase, pull requests and resolving merge conflicts. And while an IDE can make the later one a lot less painful, I have no idea how VisualStudio express performs in that regard...

Well, git was created specifically for collaboration. And as you pointed out, it needs a lot more outside of the single-user workflow. Besides that, the single-user workflow is already more complicated than necessary and far from being simple. No other tool exposes the index that much, or even apply the divide of commit and push/pull on the user in this freaky way (pull is practically auto-merging). Heck, even a local repo you want to have as push/pull target needs that weird "bare repo" configuration.

And I disagree with the notion that git is so complicated because the features are so powerful. Mercurial is as good as git in this regards (it even has more features), but with a much better interface.

But as I wrote before: git won the popularity game. As a consequence, it is ubiquitous, is integrated everywhere, offers a broad palette of helper tools, has incredible support in the internet. All that despite its arcane syntax, obscure terminology and freaky design decisions. It may be a foreign language to speak, but one you will have to learn as good as possible if you want to live in the open source community.

And now I stop my DVCS talk again. I have done my fair share of it here years ago already, and got a bit tired of the topic.

#### Urwumpe

##### Not funny anymore
Donator
Oh well, before we get a Mercurial vs git flamewar here. ?

Maybe I should write a short git tutorial for the interested beginners.

#### jedidia

##### shoemaker without legs
Mercurial is as good as git in this regards (it even has more features), but with a much better interface.
I have never used Mercurial, but I will certainly not disagree that Gits interface is... unfortunate.
Maybe I should write a short git tutorial for the interested beginners.
There's plenty of those to go around. The major stumbling block for me in the beginning was that I just didn't get how the thing works, so I kept messing up ( I mean, something as innocent as amending a local commit because you spotted a typo in the commit message while already having it pushed to the remote can really ruin your day when you're new to Git!). A tutorial that covers all those little mishaps you tend to make at the start, how to fix them, and why exactly it is that what you did was wrong, inevitably becomes a curriculum...

#### JDat

##### Active member
Git was made by linux kernel developers for linux kerner development. Somehow linux is working, so, blame to git sounds like lack of understanding and knowledge how to use it.

#### JDat

##### Active member
Not the most important thing, but MFD template and AscentMFD won't compile for x64.
I am far away from my VS2019 machine and git, so, please check, fix and compile if you have spare time.
Looks like there are problems with MsgProc return value.
Need to be LPARAM (???) instead of int.
Affected files and lines:
MFDTemplate.h : 26
MFDTemplate.cpp : 107
AscentMFD.h : 23
AscentMFD.cpp : 170

#### jedidia

##### shoemaker without legs
blame to git sounds like lack of understanding and knowledge how to use it.
I don't think anybody here said anything different. The trouble we're having is that for collaboration on the source code, a lot of people have to start using it that in fact don't know how to use it. And if your memory is intact, you will probably remember how painful the learning process was...

#### Urwumpe

##### Not funny anymore
Donator
I don't think anybody here said anything different. The trouble we're having is that for collaboration on the source code, a lot of people have to start using it that in fact don't know how to use it. And if your memory is intact, you will probably remember how painful the learning process was...

I will likely be going to teach people how to use git in a few weeks (Will be the first time I do that outside my department and the first time as a classic trainer instead of the usual mentoring). I know the pains - and even I still feel like a terrible noob there sometimes. Despite using it for years, I still feel insecure if I really remember the less often used commands correctly and really hope to be more competent when needed, as I perceive myself.

#### kuddel

##### Donator
Donator
@DarkWanderer : Since you seem to have "created" the CI, I have noticed something:
The library Orbitersdk\lib\Orbiter_server.lib usually was named just Orbitersdk\lib\Orbiter.lib, shouldn't we keep it that way?
Possibly a rename in martins build-scripts did this, or the project files should be unified to do this consitently in all Configurations (win32/x64 Debug/Release)

#### martins

##### Orbiter Founder
Orbiter Founder
This is probably my fault. The two orbiter.exe targets (.\orbiter.exe and .\Modules\Server\orbiter.exe) are known to cmake by their target IDs "Orbiter" and "Orbiter_server" (since you can't have two targets with the same name). Usually orbiter.lib is generated by building .\orbiter.exe, but in the x64 version that target isn't built, so the input library has to be generated from building .\Modules\Server\orbiter.exe. The generated binaries derive their names from the target IDs unless explicitly modified. I did modify the name for the exe (so it generates .\Modules\Server\Orbiter.exe instead of .\Modules\Server\Orbiter_server.exe), but apparently that didn't carry over to the input library. I'll see if I can fix that.

#### martins

##### Orbiter Founder
Orbiter Founder
Should be fixed now. Please let me know if there are still issues with this.

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
If you change this:
Code:
set_target_properties(Orbiter
PROPERTIES
RUNTIME_OUTPUT_DIRECTORY ${ORBITER_BINARY_ROOT_DIR} COMPILE_DEFINITIONS INLINEGRAPHICS ENABLE_EXPORTS 1 FOLDER Core ) To This: Code: set_target_properties(Orbiter PROPERTIES LINK_FLAGS "/SUBSYSTEM:WINDOWS" RUNTIME_OUTPUT_DIRECTORY_DEBUG${ORBITER_BINARY_ROOT_DIR}
RUNTIME_OUTPUT_DIRECTORY_RELEASE \${ORBITER_BINARY_ROOT_DIR}
COMPILE_DEFINITIONS INLINEGRAPHICS
ENABLE_EXPORTS 1
FOLDER Core
)

It "should" fix the problem with binaries ending up in "Debug" "Release" sub-folders

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
When migrating the D3D9Client into the Orbiter repository what's gonna happen for the project history. For me it really doesn't matter. I am just asking if I should import the project history from SVN to Git or Not ?

Replies
101
Views
7K
Replies
74
Views
5K
Replies
13
Views
3K
Replies
10
Views
272
Replies
36
Views
4K