x64 Development

jangofett287

Heat shield 'tester'
Joined
Oct 14, 2010
Messages
1,150
Reaction score
13
Points
53
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 :D
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
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
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
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
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.
200.gif


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. o_O
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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").

1628037974492.png

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.
1628038331520.png

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
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
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
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
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
Joined
Sep 6, 2010
Messages
105
Reaction score
74
Points
43
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
Joined
Sep 6, 2010
Messages
105
Reaction score
74
Points
43
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
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
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
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
@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
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
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.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
If you change this:
Code:
set_target_properties(Orbiter
PROPERTIES
LINK_FLAGS "/SUBSYSTEM:WINDOWS"
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
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
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 ?
 
Top