Remove "its" support as part of rspec-core issue #1083

[palfvin]

This is step 2 of the 3-step process to extract "its" support to separate gem, per #1083

[coveralls]

Coverage increased (+14.51%) when pulling 7d7974d on palfvin:master into 2ecfec8 on rspec:master.

[JonRowe]

Two commits with the same description?

[JonRowe]

Needs a changelog entry but otherwise looks good to me,

[coveralls]

Coverage increased (+14.51%) when pulling 0ff583c on palfvin:master into 2ecfec8 on rspec:master.

[coveralls]

Coverage increased (+14.51%) when pulling 066fb29 on palfvin:master into 2ecfec8 on rspec:master.

[JonRowe]

Could you squash this into 1/2 commits? (I'm ok with the changelog being one commit but the others need only be one commit)

[xaviershay]

I typically include the changelog in the same commit as the actual change. Then if it gets reverted it disappears as well.

[JonRowe]

We've never enforced a commit per PR rule, (just a sensible number per) so I'm not going to enforce that here, besides, can always revert the merge commit.

[palfvin]

Guys, I don't know git well enough to do what you're asking without researching it. I can fork a new repository and submit a new pull request with a single commit. Would that be ok?

[xaviershay]

Here's how:

git rebase -i HEAD~2
# Change second commit from "pick" to "s"
# Save and quit.
# You'll be prompted for a combined git message, edit that to taste.
git log -n 2 # Should see one commit which is yours, and one you based off (i.e. not yours)
git push origin master -f # Force push your master branch

Give it a try! If it doesn't work I can squash them for you.

[JonRowe]

Run git --rebase interactive on your branch and in your editor (:i if vim) replace all apart from one pick with squash so you end up with:

pick {hash} {message}
squash {hash} {message}
squash {hash} {message}
squash {hash} {message}
squash {hash} {message}
... (etc)

Save and quit whichever editor it uses (:wq if it's vim) then reword the commit message, and run git push origin master -f

[JonRowe]

Or what @xaviershay said

[xaviershay]

haha, race condition, I win :P

Yours is probably a better description though.

[palfvin]

I was never prompted for the combined commit and got this output:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git reset'

[JonRowe]

Did you follow my instructions or @xaviershay's? You actually do need to specify the commits to squash unforunately because you didn't branch off first. Either use git rebase --interactive HEAD~6 or git rebase --interactive origin/master

[palfvin]

I followed yours. Here's what I saved from the first edit:

pick a93acb8 Remove its support
squash 7d7974d Remove its support
pick 066fb29 Update changelog

# Rebase a9c81cb..066fb29 onto a9c81cb
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Here is the output:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git reset'
# Not currently on any branch.
nothing to commit (working directory clean)
Could not apply a93acb8... Remove its support

Then I did git rebase --abort.
Then I did git rebase --interactive origin/master and was thrown into the
editor with the following:

noop

# Rebase 066fb29..066fb29 onto 066fb29
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

I don't know what to do next.

[JonRowe]

Can you pop into #rspec on irc.freenode.org?

[JonRowe]

If not the basic gist is you must have an empty commit or something, you can use git show {hash} to see what a commit contains, and you can use git log to show the hashes of your commits in your master.

[JonRowe]

Thanks a lot, I'll merge when Travis goes green

[coveralls]

Coverage decreased (-0.09%) when pulling fa69345 on palfvin:master into 2ecfec8 on rspec:master.

[palfvin]

@JonRowe Thanks. Any idea why some of the code block markdown in my earlier comments didn't "take" (and some did)?

[JonRowe]

Nope, it's completly valid ( a new comment renders fine)

[palfvin]

@JonRowe FYI, I contacted github support about why my markdown didn't work and they said it's not supported for comments posted via email.

[JonRowe]

Yeah I've noticed this a few times now (/cc @parndt)

[parndt]

Yeah, it's a real frustration. You can't even edit the comment afterward on the UI! :)