I agree on the change and think the potential runtime breakage sounds reasonable.

From IComparer<T>

Defines a generalized comparison method that a value type or class implements to create a type-specific comparison method for ordering or sorting its instances.

Can we offer an alternative or guidance for users who still want to test that two items are equal using their CompareTo method?
Ugly workarounds would be

subject.Should().BeLessOrEqualTo(expected)
    .And.BeGreaterOrEqualTo(expected);

subject.Should().BeInRange(expected, expected);

Explicit test but inferior failure message.

subject.CompareTo(expected).Should().Be(0);

How about naming it subject.Should().BeRankedEqualTo(expected)?
About guidance, when such a method exists an explanation and reference can be included in the comments of Be and NotBe.

How about naming it subject.Should().BeRankedEqualTo(expected)?

Love that one. Probably should be BeRankedAsEqualTo

@rubenrorije are you planning to add that BeRankedAsEqualTo?

Sorry, made the same git mistakes again. I am obviously still a noob on the git part. I will try to fix this.

Could you give me some pointers to resolve the git issues here? I assume that the rebase I did resulted in the commits 9050e37 and c477f8b to be included. But I am a bit lost how to resolve this. My solution would be to create a new branch and cherrypick commits, but that seems like an extreme solution that should not be necessary.

@rubenrorije It looks like you pulled master after rebasing on it.
When rebasing, you'll need to push force.
git push --force/git push -f (There's also a --force-with-lease option that does some additional checking)

In git commits are identified by a hash value computed on the difference between the commit and its parent commit.

Before rebasing both your local branch and the remote branch on github looks like:

master --> ... --> HEAD
 |
 + --> PR1177

After rebasing your local branch the picture is now
local:

master --> ... --> HEAD
                    |
                    + --> PR1177' // note the '

remote:

master --> ... --> HEAD
 |
 + --> PR1177

As PR1177 and PR1177' has different parent commits locally and remote, git sees them as two different commits.
This step can be confusing as git will now report that there are remote changes, which your local branch does not have.
It's technically true, due to different hash values, but we know it's because of our rebase.

So if you pull master instead of force pushing the local picture becomes:

master --> ... --> HEAD
                    |
                    + --> PR1177 --> PR1177'

If you rebase again on master, you can remove the unwanted commits from the history of this branch.
I usually do this via terminal

git rebase -i master

The terminal opens some editor (for me it's Vim)
I then write replace pick with drop for the commits I want to remove.
Save the file and exit.
The rewritten history can be seen with
git log master...
Then git push -f to push the local branch to the remote repository.

Thanks for the extensive explanation. That made things much clearer. I was able to fix the issues now. I did not want to screw everything up again by rebasing again. When the pull request is not accepted directly it must be done again anyway.

I haven't fallen in love with BeRankedAsEqualTo (yet), so I would like to brainstorm a bit on the naming before settling.

• BeComparableTo
• CompareEqualTo
• RankEqualTo
• BeEqualTo

BeEqualTo is not used anywhere else and it's in line with naming of e.g. BeGreaterThan, but I'm not sure whether it's confusingly close to Be

I agree discussing this a bit more might be useful. I do not have a strong preference.

BeEqualTo is not used anywhere else and it's in line with naming of e.g. BeGreaterThan, but I'm not sure whether it's confusingly close to Be

If I would see the options Be and BeEqualTo after typing Should() I would (wrongfully) assume from the method names that Be checks reference equality and BeEqualTo equality. When also considering the similarly named BeEquivalentTo, it might not be that intuitive which one does what.

Slightly related and maybe against the whole idea of the project, but I think it would be nice to have one (additional?) function to check all comparisons:
subject.Should().BeComparable(instanceLess, instanceEqual, instanceGreater, because) that combines all checks. I assume this is done now by multiple test methods and/or multiple assertions within a test method.

I could live with BeComparableTo, but not with the others.

What about BeRankedEquallyTo?

I'm fine with BeRankedEquallyTo.

I do not have any preference, so I renamed the methods.

What's stopping us from merging this one?

Now the unit test is failing on the changed message.