[IMPORTANT] How to contribute code

[karvanit]

One feature in each PR, each PR in a separate branch, is the best way. Doing it like this, it's FAR easier for the integrator, and other people can easily help / comment / test on each feature.

Also, IMO, try to keep each commit clean and making a single (conceptual) change. eg HyperDecoder Ufopaedia, HyperDecode base facility, HyperDecoder UFO reporting = 3 commits. This makes it easier to comment / fix bugs, and to review the code changes.

Git tip: Try having a devel-feature local branch where you can do the actual work and mess with the history as often as you like (eg git rebase -i, git cherry-pick), and a clean feature branch you will push to GitHub.

[Warboy1982]

so this would be the sort of pull request you'd LIKE to see?

https://github.com/SupSuper/OpenXcom/pull/184

[karvanit]

Speaking only for myself, I consider this form of PR extremely pullable!

[SupSuper]

Yeah, I've accepted it now. I usually don't have much comment on them, but the problem with pull requests is the bigger they are, the longer they take to review (gotta make sure nobody's sneaking any viruses or something ) and the more likely they will conflict with some minor change, which just makes the merging process even more manual so I keep putting it off and... yeah.

[Fenyő]

@SupSuper: Hmm, maybe this is the reason you haven't accepted my PR yet?
Do you want me to slice it to more commits?
Or maybe i can tell its way of work,  d' you want that?

[SupSuper]

@SupSuper: Hmm, maybe this is the reason you haven't accepted my PR yet?
Do you want me to slice it to more commits?
Or maybe i can tell its way of work,  d' you want that?

You'll just have to be patient, no matter how you slice it, eventually all these huge pull requests are gonna touch the same files and I have to merge them in manually.

[Fenyő]

May i ask which Pull-request is conflicting with mine?

[SupSuper]

May i ask which Pull-request is conflicting with mine?

The conflicts were in the project files since you all change those.

[karvanit]

Another think to know / use:

When making git commits, the first line should be short (up to 50 characters), and be a meaning full description/title.
The next line should be empty.
This way the git history looks much nicer.

[Warboy1982]

The next line should be empty.

rrrrgh, sorry about this.
i thought i was doing it right, but i completely missed that there should be a blank line.
rest assured any future commits from me WILL conform to this standard.

[Juju Dredd]

Always create new branch (for new issue /PR) from actually SupSuper/OpenXcom/master

Example:               (https://git-scm.com/downloads)

Thanks for this picture, I see I created my branch the wrong way.
Could somebody explain what the boxes "Tracking Branch" "Fast forward only" "Fecth tracking branch" are for?

Please please please, could someone reveal me the keys of (tortoise) git mysteries...

Edit: Oh no, I understand now, aliens must have abducted me and put something in my brain preventing it from functioning normally, you do not speak about TortoiseGit but GitGui...

[Juju Dredd]

Could anybody tell me why I get a "Anonymous access denied" from GitHub when trying to push with TortoiseGit? Because I tried to configure a private/public key, and I must give my GitHub login and password. This is a strange anonymous access I believe...

Edit: OK, I made it, I just spent only five hours to do that simple operation...