Learn to rebase you butts

[Miauw]

Are you tired of thousands upon thousands of ugly merge commits, screwing everything up and inflating your PR like a balloon?
Worry no more!
For there is a way to avoid this: REBASING.

For those of you who use Tortoisegit, just select "Rebase" in the context menu, select "master" in the Upstream: field and just hit "Start Rebase"!
That's really all there is to it. If you get conflicts, it will say so at the bottom. Resolve these conflicts as you would normally and hit "Continue".
After that, all you have to do is FORCE (this part is important, you're overwriting your previous commit) push your branch to origin and you are DONE!

[Remie Richards]

Or you could do the sane thing and squash them.

I even wrote this guide ages ago:
https://tgstation13.org/wiki/Setting_up ... ptional.29

[phil235]

Or you could do the sane thing and squash them.

I even wrote this guide ages ago:
https://tgstation13.org/wiki/Setting_up ... ptional.29

The 'combine to one commit' option doesn't exist for me, I think the guide is outdated.

[Scott]

or you could use the command line and stop being scrubs

[Remie Richards]

Or you could do the sane thing and squash them.

I even wrote this guide ages ago:
https://tgstation13.org/wiki/Setting_up ... ptional.29

The 'combine to one commit' option doesn't exist for me, I think the guide is outdated.

Well shit, really glad I haven't updated my tortoisegit in a while.
Edit: According to the patch notes it hasn't been removed, perhaps just relocated.

[Mandurrh]

I have a few other ones too!

http://pastebin.com/stbn2Dpg

http://pastebin.com/hAtgdSAq

[Remie Richards]

I have a few other ones too!

http://pastebin.com/stbn2Dpg

http://pastebin.com/hAtgdSAq

git reset --soft HEAD~X

soft HEAD

must... resist... joke...

[MisterPerson]

Or you could stop worrying about it because it doesn't fucking matter.

[Cheridan]

Or you could stop worrying about it because it doesn't fucking matter.

I generally don't care but there's points where newbies get more commits than characters changed in their PRs and it becomes ridiculous.

[Incoming]

I like getting pulls merged with a low number of commits because it shows that I didn't cock up balance/functionality for it too badly on my initial write. It's like solving puzzles in a low number of moves.

[Mandurrh]

Or you could stop worrying about it because it doesn't fucking matter.

I generally don't care but there's points where newbies get more commits than characters changed in their PRs and it becomes ridiculous.

Me. I always think it'll be just one then it's 10 changes asked for or needed or I forgot something and I have to squash so I don't die from shame.

[Not-Dorsidarf]

You can't handle my 23-commit 20-lines-changed PR! You can't handle my 300 files changed 1 line of code changed PR!

[Miauw]

Or you could stop worrying about it because it doesn't fucking matter.

rebasing has less of a chance to fuck up and give your PR 5000 commits and 5456132 million lines changed.

[MisterPerson]

I would actually argue that telling a beginner to rebase is more likely to cause their pull request to be fucked up than less.

[oranges]

rebasing on top of master is literally a completely safe operation.

it's the force push to the repository after that can bring danger.

But anyone should be able to grasp how to use it.

[MisterPerson]

Even still, it doesn't do any useful function. Mixing in unnecessary commits with your pr's branch is a sign of a bad merge and would need to be corrected anyway. No need to fix a problem that doesn't exist yet.

[oranges]

no merge commits, plus a maintainer can do a fastfoward merge of your PR which means they can revert it easy since there isn't a merge commit which are unrevertable.

[MisterPerson]

What do you mean unrevertable? Of course they're revertable. If they weren't, we wouldn't be able to use them at all because the merge of the pull request itself makes a merge commit. Github was just fine with me making a revert branch for pulls that contained merges (with an s) before the main merge, so I'm going to say with firsthand experience that you're wrong.

The only way to do a "fastforward merge" (which I'm assuming to mean a merge without a merge commit, because frankly it sounds like you're making shit up) would be to have the merge itself be a rebase from the merging branch onto the primary branch. Which would be great if we were using Phabricator. But we don't. And even if we did, avoiding merge commits doesn't mean anything to begin with. It's not a useful goal to strive for because there's no gain from doing so other than to appease some people's obsessive, retarded, unjustified hate of them.

[oranges]

http://ariya.ofilabs.com/2013/09/fast-f ... merge.html

I wasn't quite accurate by stating that a merge commit is unrevertable, you can, but it does cause issues when you want to then later bring that code back in

see here
http://git-scm.com/blog/2010/03/02/undoing-merges.html