Getting Your Pull Accepted - Revision history

Covertcorvid: /* Pull Request Requirements */ Added sections about porting upstream and GitHub overrides

2023-03-30T06:09:35Z

Pull Request Requirements: Added sections about porting upstream and GitHub overrides

imported>Kosmos: /* How to Deal with Merge Conflicts */ Updated the dealing with merge conflicts guide

2017-07-30T17:38:41Z

How to Deal with Merge Conflicts: Updated the dealing with merge conflicts guide

imported>Factoryman942: /* 1. You must follow the coding standards */

2017-02-10T00:07:44Z

1. You must follow the coding standards

imported>Oranges: Undo revision 17378 by Oranges (talk)

2016-12-02T23:37:47Z

Undo revision 17378 by Oranges (talk)

imported>Oranges at 23:33, 2 December 2016

2016-12-02T23:33:39Z

imported>Bandit at 06:45, 28 August 2015

2015-08-28T06:45:26Z

imported>Kosmos: /* How to Deal with Merge Conflicts */ ok so solving merge conflicts is better through push but of course i have no conflicts right now

2015-06-10T18:08:20Z

How to Deal with Merge Conflicts: ok so solving merge conflicts is better through push but of course i have no conflicts right now

imported>Kosmos: Added steps to dealing with merge conflicts, still a wip

2015-05-03T05:33:31Z

Added steps to dealing with merge conflicts, still a wip

imported>Oranges: Small spelling issue

2014-12-11T21:38:46Z

Small spelling issue

imported>Oranges: Update commitlogs with changelog options

2014-12-11T21:38:12Z

Update commitlogs with changelog options

@@ Line 1: / Line 1: @@
 So you've made a change to the code/sprites and want to make a Pull Request so it can be added to the game!
-Before you do this, though, there are have some requirements so your code doesn't make SS13's infamous spaghetti code problems even worse.  Make sure your code fits these requirements or your pull will not be accepted.  You may also want to read through the suggestions section.
+Before you do this, though, there are have some requirements so your code doesn't make SS13's infamous spaghetti code problems even worse. Make sure your code fits these requirements or your pull will not be accepted. You may also want to read through the suggestions section.
 = Pull Request Requirements =
 === 1. You must follow the coding standards ===
 Please read through these [[Coding Standards]]. The standards will change over time. Hopefully you already read through and made sure your code adhered to them before opening your pull request!
 === 2. Your code must compile. ===
-This is a given.  While your pull request will not be closed over this, it will not be accepted until it does compile cleanly.  The [https://travis-ci.org/tgstation/-tg-station Travis] bot will check for this automatically, but you should check before you even commit. Warnings should also be cleared.
+This is a given. While your pull request will not be closed over this, it will not be accepted until it does compile cleanly. The [https://travis-ci.org/tgstation/-tg-station Travis] bot will check for this automatically, but you should check before you even commit. Warnings should also be cleared.
 Sometimes Travis is a silly bot and something unrelated to your code causes his compile to fail. If this happens you can force a rebuild by closing and reopening your pull request. Alternatively, you can ask a maintainer to force a rebuild from the Travis page (must be logged in).
 If you change an object's path, you must update any maps that have that item placed on it. Travis checks all maps, including Ministation and Metastation. If Travis is failing you after a path change and you don't know why, check the other maps!
 === 3. Do not automatically add FILE_DIR. ===
-A recurring problem is people adding commits that needlessly spam changes to the DME due to having "Automatically add FILE_DIR" set in their project settings.  You'll know if you have this problem if you see this in your commit (as seen through github):
+A recurring problem is people adding commits that needlessly spam changes to the DME due to having "Automatically add FILE_DIR" set in their project settings. You'll know if you have this problem if you see this in your commit (as seen through github):
 [[Image:Fucking_FILE_DIR.png|600px|center]]
 PRs that add things to FILE_DIR will be rejected.
@@ Line 28: / Line 22: @@
 # Check compile.
 # Close DreamMaker and commit again.
 === 4. Pull requests must be atomic ===
-Pull requests must add, remove, or change only ONE feature or related group of features.  Do not "bundle" together a bunch of things, as each change may be controversial and hold up everything else.  In addition, it's simply neater.
+Pull requests must add, remove, or change only ONE feature or related group of features. Do not "bundle" together a bunch of things, as each change may be controversial and hold up everything else. In addition, it's simply neater.
 Bugfix-only PRs are granted some leniency, however not all bugfixes are made equal. It's possible to have a change that technically fixes a bug, but does so in a way that's hacky or otherwise undesirable.
 === 5. Make explicit commit logs ===
 Be clear in exactly what each of your commits do. Esoteric or jokey commit logs are hard for future coders to interpret which makes tracing changes harder. Don't make it too long however since an actual description of your changes goes into your pull request's comment. Ideally the first line should be a short summary, then you have a more fleshed out commentary below that.
@@ Line 39: / Line 31: @@
 Make sure you also add a changelog entry if you're making a big player facing change.
 The guide to adding changelogs can be found in the [[Guide_to_Changelogs]]
 === 6. Clearly state what your pull request does ===
 Don't withhold information about your pull request. This will get your pull request delayed, and if it happens too often your pull request will be closed.
@@ Line 49: / Line 40: @@
 In this PR I fixed bug #1234.
 </pre>
 '''Acceptable:'''
 <pre>
 In this PR I fixed bug #1234 and also modified the baton's name and description.
 </pre>
 == How to Deal with Merge Conflicts ==
 Most of the time, Git is pretty smart about merging code files. However, if one PR is merged before yours that edits the same file, your PR will be in a state of conflict and will not be able to be automatically merged via GREEN BUTTON. Because there are more contributors than there are maintainers, most of the time resolving these conflicts falls to the maker of the PR.
@@ Line 72: / Line 71: @@
 If it's a map file that's conflicted, remember to start the [[Map Merger]] before you pull from upstream.
 {{Contribution guides}}
 [[Category:Game Resources]] [[Category:Guides]]

@@ Line 56: / Line 56: @@
 == How to Deal with Merge Conflicts ==
 Most of the time, Git is pretty smart about merging code files. However, if one PR is merged before yours that edits the same file, your PR will be in a state of conflict and will not be able to be automatically merged via GREEN BUTTON. Because there are more contributors than there are maintainers, most of the time resolving these conflicts falls to the maker of the PR.
-Fixing merge conflicts with TortoiseGit's rebasing:
+An easy way to fix merge conflicts is to make a new branch (you should especially do this if your PR is just a small one):
-# Right-click your working folder, go '''TortoiseGit''' --> '''Pull...'''
+# Switch to your master branch: Right-click your working folder, go '''TortoiseGit''' --> '''Git Switch/Checkout...'''
-# On the top, from the '''Remote'''-list, select '''upstream''' and from the '''Remote Branch'''-list select '''master'''.
+# Look at the '''Branch'''-list and select '''master'''
-# Click '''OK'''.
+# Close the window that pops up (assuming it changed successfully)
-# This part needs a good guide how to actually use the merge-conflict-yellow-orange-program (I can't remember how it goes and don't have any actual merge conflicts now)
+# Right-click your working folder, go '''TortoiseGit''' --> '''Git Pull...'''
-# Right-click your working folder, go '''TortoiseGit''' --> '''Push...'''
+# On the top, from the '''Remote'''-list, select '''upstream''' and from the '''Remote Branch''' -list select '''master'''.
-# Push as you would normally, except down in '''Options''', next to '''Force:''' select '''known changes'''.
+# Close the window that pops up (assuming it updated successfully)
-# Click '''OK'''.
+# Make the same exact changes to the code which you have on your PR

@@ Line 6: / Line 6: @@
 === 1. You must follow the coding standards ===
-Please read through these [[Coding_Standards]]. The standards will change over time. Hopefully you already read through and made sure your code adhered to them before opening your pull request!
+Please read through these [[Coding Standards]]. The standards will change over time. Hopefully you already read through and made sure your code adhered to them before opening your pull request!
 === 2. Your code must compile. ===

@@ Line 3: / Line 3: @@
 Before you do this, though, there are have some requirements so your code doesn't make SS13's infamous spaghetti code problems even worse.  Make sure your code fits these requirements or your pull will not be accepted.  You may also want to read through the suggestions section.
-This has been moved to here: https://github.com/tgstation/tgstation/blob/master/CONTRIBUTING.md
+= Pull Request Requirements =
 {{Contribution guides}}
 [[Category:Game Resources]] [[Category:Guides]]

@@ Line 3: / Line 3: @@
 Before you do this, though, there are have some requirements so your code doesn't make SS13's infamous spaghetti code problems even worse.  Make sure your code fits these requirements or your pull will not be accepted.  You may also want to read through the suggestions section.
-= Pull Request Requirements =
+This has been moved to here: https://github.com/tgstation/tgstation/blob/master/CONTRIBUTING.md
 {{Contribution guides}}
 [[Category:Game Resources]] [[Category:Guides]]

← Older revision		Revision as of 06:45, 28 August 2015
Line 56:		Line 56:

	== How to Deal with Merge Conflicts ==		== How to Deal with Merge Conflicts ==
		+
		+	'''DON'T USE THIS GUIDE, IT WILL BREAK EVERYTHING'''

	Most of the time, Git is pretty smart about merging code files. However, if one PR is merged before yours that edits the same file, your PR will be in a state of conflict and will not be able to be automatically merged via GREEN BUTTON. Because there are more contributors than there are maintainers, most of the time resolving these conflicts falls to the maker of the PR.		Most of the time, Git is pretty smart about merging code files. However, if one PR is merged before yours that edits the same file, your PR will be in a state of conflict and will not be able to be automatically merged via GREEN BUTTON. Because there are more contributors than there are maintainers, most of the time resolving these conflicts falls to the maker of the PR.