Aaargh, GitHub pain:
"This branch is 65 commits behind x:master."

So GitHub ffs, give a bl**ding button that says "Sync" instead of a long f***ing series of steps I have to complete for something that should just be a single god*mn click.

git pull upstream && git push

^ this.
Also, does github have remote pull requests? Those are a remote merge option that's fairly painless too...

@codeclod those are ugly. Each of them creates a "Merge pull request" something which then leaves traces in upstream's history. I was trying to get around it, but I got the same answer even from github support as I thought - no-go. Either through github and with traces, or the pretty way through console. But, well... if you have only a phone available, sometimes it gets messy.

@KeyWeeUsr I actually like the merge commits. They preserve the merge history and make it easy to revert merges using revert. It's largely preference though. We use Bitbucket server at work and the newest version lets you choose the merge strategy if you want to avoid merge commits.

@codeclod I don't mean casual merge commits. I mean merge commits a user brings if (s)he wants to make a pull request. This way you will have dirtier master, because someone is merging through web. It's ok if there isn't a lot of such commits.

@KeyWeeUsr I guess I'm unfamiliar with what you're talking about. When we do them, they create the request through the web, and when merged, there's only the one merge commit. There may or may not be any from their source branch, but the request itself is only the one. Maybe I just don't consider it "dirty". To each their own though. ☺

@codeclod Let's have an upstream and a fork. Fork is behind, you'll sync via github. It'll pop some PR window or what(can't remember). Fork is up-to-date with upstream.

A change(commit) was introduced in the fork, a user made PR from fork to the upstream. PR in the upstream shows a commit about merge (Merge PR #) from fork, then the actual commit. The merge commit has diff +0/-0. This merge part is ugly _and_ should be definitely filtered if not removed completely from upstream. Some can think a user can't sync with console, which makes contributor look inexperienced.

This sound like a point at which I'd copy my changes to another folder, delete the .git folder and work from there lol Either that or try a git rebase

@kshep92 why? If the upstream has higher priority, just put your stuff on a different branch, pull from upstream and then deal with the stuff locally. Look at the changes, conflicts and merge incrementally. Mostly it is quite easy (though not pleasant) to do.

@KeyWeeUsr I think you're missing the point of the merge commit in the first place. It's obviously going to show +0/-0, but the utility is that to show the merge history, which is actually important to many, especially when you're working with multiple devs on a single repo. The fact that it "clutters" the upstream history is purely pedantic.

@KeyWeeUsr why? Because I'm one lazy SoB that's why 😆