/tg/Station 13

What are the correct steps to solve a merge conflict for our environment?

The guide put on the wiki has a very big DONT DO THIS printed above it but doesn't give the correct way.

It varies slightly but here's the run down.

1:) Save all changes you've made, revert anything you have no intention of keeping.

2:) Right Click your -tg-station folder, hover 'TortoiseGit' and click the 'Pull' button.

3:) Using the code base remote (I named it upstream) pull the new code to the 'Master' branch, DO NOT pull the changes to the branch you are currently working on as this won't work.

4:) You'll receive a error when the pull attempt finishes, accept this and you'll see a menu allowing you to observe the changes between the two codes, yours and the new one, hit accept.

5:) From this menu you'll be displayed all the files in the code base, and any of YOUR OLD code files that are conflicting with the NEW CODEBASE files will be highlighted in red. From here simply right click any and all conflicting files and save using the new code.

6:) Hit the 'Push' button (or whatever) to save the changes.

From here you now need to go to all the files that were conflicting and re-add the code changes you added. You only have to do this for code files that were conflicted and were overwritten.

Addendum: If you have a conflicting map file what I recommend you do is copy+paste the map changes you've made into a new map files somewhere else, then when you've finished fixing the merge conflict simply take that and copy+paste it back into the map. Just make sure you're not overwriting anything by accident.

It just says it is already up to date if I try step 3.

Scratch that I meant you need to get the code from the "upstream" branch.

Also known as the branch the code is held for /tg/.

Steelpoint wrote:Scratch that I meant you need to get the code from the "upstream" branch.

Also known as the branch the code is held for /tg/.

But that just updates my master branch.

Steelpoint wrote: 3:) Using the code base remote (I named it upstream) pull the new code to the 'Master' branch, DO NOT pull the changes to the branch you are currently working on as this won't work.

You mean don't pull /tg/ master to my current local branch (eg: BEES_glorsious_BEES)? if so you're totally wrong and the evidence is every merge conflict I've ever solved.

Yeah uh steelpoint you're SUPPOSED to pull to the current branch... NOT to master

how to fix conflicts:
1. git pull upstream master
2. git status
3. manually fix conflicts in the code
4. git add [full path and filename of conflicting files. can be found with git status]
5. commit
6. push
7. roll the dice of fate
8. your PR now has 20000 lines changed
9. close it and make a new PR

step 1. use tortoise
step 2. pull from origin master to your local master before making a new branch
step 3. make the changes.
step 4. PR it.
step 5.MERGE CONFLICTS
step 6. Pull from origin master to your local branch.
step 7. RESOLVE CONFLICTS. Go to conflicted files and right click them and select "Edit conflicts" it will open a side by side comparision. Use this to make the file most correct.
step 8. COMMIT CHANGES
step 9.Push to github branch for PR.

Step 1. Stop using tortisegit, it's shit

Step 2. There is no step 2.

oranges wrote:Step 1. Stop using tortisegit, it's shit

Step 2. There is no step 2.

Never had an error yet. Not sure why its shit?

Asking people to do all their git stuff from the command line is a great way to never get any more new hobbyist coders.

It's a great way to get rid of the shit ones though.

oranges wrote:It's a great way to get rid of the shit ones though.

I can code better then half our coders and I use tortoise.

Are you going to list some names?

kazeespada wrote:

oranges wrote:It's a great way to get rid of the shit ones though.

I can code better then half our coders

hahahahahahahahahahahha

I guess the problem is that these things are rarely documented and I'm trying to work off of memory.

Yeah, better documentation is sorely needed.

kazeespada wrote:step 1. use tortoise
step 2. pull from origin master to your local master before making a new branch
step 3. make the changes.
step 4. PR it.
step 5.MERGE CONFLICTS
step 6. Pull from origin master to your local branch.
step 7. RESOLVE CONFLICTS. Go to conflicted files and right click them and select "Edit conflicts" it will open a side by side comparision. Use this to make the file most correct.
step 8. COMMIT CHANGES
step 9.Push to github branch for PR.

okay so wait i actually have a question about this. when i do step 8 it changes like 30 dozen files and what i did last time was uncheck all but the file i actually want to fix conflicts on, but this lead to having 20,000~ lines changed on my PR. am i supposed to leave all of the files ticked or ???

oranges wrote:Step 1. Stop using tortisegit, it's shit

Step 2. There is no step 2.

i use tortoisegit only for committing and pushing (and i would use it for cherrypicking too but i've never had to) since the interface for those are nicer, but i use the console for everything else (with all the commands i need in a .txt file). am i a heathen or just a half heathen

You have to leave the other files ticked.

when you commit in those circumstances what your telling the project is "this is how the project looks after I make my changes as well as other peoples changes compared to the previous commit". If you uncheck the other files that changed besides your own you're basically saying "My changes obsoleted everything that's changed in the meantime, get rid of it". Which is probably not true.

oranges wrote:It's a great way to get rid of the shit ones though.

Having to memorize text commands because someone is too lazy to make a decent UI does not make you a good coder.

Command lines were bearable in the past because the amount of programs worked with was limited and graphics were expensive.

There is literally no excuse for not making a decent UI these days.

Yes there is, UIs are slow.

Guys don't get all worked up about a flippant comment sheesh

Scott wrote:Yes there is, UIs are slow.

ohw yeah, because typing out all those commands is fast.

CLI - higher skill cap, steeper learning curve
GUI - lower skill cap, smoother learning curve

just use the one you prefer

duncathan wrote:CLI - higher skill cap, steeper learning curve
GUI - lower skill cap, smoother learning curve

just use the one you prefer

mix of both is the way to go imo

PKPenguin321 wrote:

kazeespada wrote:step 1. use tortoise
step 2. pull from origin master to your local master before making a new branch
step 3. make the changes.
step 4. PR it.
step 5.MERGE CONFLICTS
step 6. Pull from origin master to your local branch.
step 7. RESOLVE CONFLICTS. Go to conflicted files and right click them and select "Edit conflicts" it will open a side by side comparision. Use this to make the file most correct.
step 8. COMMIT CHANGES
step 9.Push to github branch for PR.

okay so wait i actually have a question about this. when i do step 8 it changes like 30 dozen files and what i did last time was uncheck all but the file i actually want to fix conflicts on, but this lead to having 20,000~ lines changed on my PR. am i supposed to leave all of the files ticked or ???

Commit changes will show that there are like 20 file changes if its larger then that then you should be updating your master more often. Commit these files as well. Also, if those files are not touched, then they will not show up on your PR. Always close DM when working with Git. DM and Git will fight each other silently for who can do what with files.

So what happens if you try the method described on the wiki?

It often fucks up your branch and is not worth the pain of fixing