difflib belongs in the group above, as it's shipped with Python.

That's kind of a long full name. How about just --update?

This is wrapped very strangely. Should be more like:
has_... = (

      self.options.guess_fields or

      (self.options.summary and self.options.description)

  )
Other valid options, though, are --guess-summary + --guess-description, so that should be handled too. Those predate --guess-fields, so people may have those set in scripts.
In fact, setting --guess-fields just sets self.options.guess_summary and guess_description, so just check for those.

Blank line before.

Summary should be on the """ line.

I'm not sure how I feel about using diff logic for this. It's very easy to get false-positives/negatives. I'd like to know what other people think.

You can avoid keeping track of the index by doing:
for seq_a, seq_b in zip(sequences_a, sequences_b):

Blank line before.

Blank line before an if.
These two can be one statement, though.

Blank line before.

This should also filter by repository. It's not valid to update a review request on a different repository.

Blank line before.

Should be:
print ('....'

       % user.username)

Just return. No exit.
Same below.

Blank line before.

Blank line before.

Wrapping is best done as:
question = ('...'

            % (request.id, request.summary))
Also, space after ":"

I don't like always having to be asked. The majority of the time, things will be identical, and I can feel safe about that. Instead, I'd want to know if they're an exact match, or a fuzzy match.
Thinking about this more, I think I'd prefer the following logic:

If the sets of fields are identical, assume it's the correct one.
If the summary is identical, but the description is different, prompt.

That way, we can be pretty sure in the common case that nothing has changed, and in the case of the description being augmented, we can confirm. The user has a clear expectation of what will happen in each case, and doesn't have to worry about how different the summary/description is.
That also avoids things like a summary of "Fixes bug 123 in my module" from appearing to be a valid option when compared against "Fixes bug 124 in my module".

Blank line before.

Sounds more human if you say ".. the existing review request"

Any modifications to existing command options, or behavior need to be updated in the documentation as well (This includes adding commands such as in your other review requests).
see "rbtools/docs/rbtools/rbt/commands/post.txt"

This seems like it could be useful outside of post, such as in your command for generating configuration. I could imagine uses in other commands, or new commands as well.
How about we move this out to utils or something?

I'm not sure if this is true. Let's assume we don't have --guess-fields set, and we aren't provided a summary or description:
We could still detect they'd like to update, and run the code to guess the fields to generate them, but we just won't update the fields when we update the request.

I think this might be better suited outside of "post_request()".
It would be nice if we could minimize the complexity of the method, and instead just have the guessing code live somewhere else that possibly runs first.
How about we refactor post_request() to take the review request ID as an argument, defaulted to None. If it is None, we create the new review request, and if it's provided we update that one?

Like I mentioned in r/4662 , API resources are paged, so just looping through the first page will not retrieve every resource. See my comment in the other review request.

Needs two colons at the end, to trigger the code block for the next line. (It's a ReST construct.)

"Determine the existing review request to update."

"Guess" doesn't really say what it's doing with this. I'd specifically say "Return the summary ..."

Same here.

"Return the revision ..."

You can just return in the above, instead of at the end.

Blank line between these.

What happened with this logic?

There's a lot of code repeated here. I'd suggest having the conditionals compute the revision only, and then do the whole execute () at the end of the function.

Same here.

"Returns the ..."

"Returns the ..."
Make sure the rest of the change is in that format. "Gets" doesn't mean it's returning anything it just means it's getting something from somewhere.

Blank line before this.

Should follow the standard format of:
"""One-line summary.

Multi-line description.
"""

Since r1 and r2 aren't used, you can just do:
revision = self._extract_revisions(...)[1]

Same here.

Might as well store as rev1, and not rename a variable.

Parent branch of what? The docs should be explicit, so there's no uncertainty about what it's based off of.

"Returns"
Can you explain more what this function does? From the description, it's not immediately obvious what this data is or where the information is coming from.

You don't need the `` in the summaries. It's best not to specify the variable names in summaries, actually. Say something like "the provided revision range."

Blank line before this.

Terminology is "review requests", specifically. "requests" usually means something else, like an HTTP request.
Can you also update the variable names to be review_request, and not request?

Comments should be in sentence casing, ending with a period.

Can you use "ID" instead of "id" in the docstring?

Blank line before this.

You can just do:
if not requests:

This sounds like an error. We should fail without a successful return code.

No need for the parens.

The comments shouldn't go between the conditionals. Try rewriting to describe what's happening when it hits that conditional, and put them inside the body.

Same comment about review_request vs. request.

This is also an error, so we need to fail with an error.

Just about there. A few things left, plus some other stuff that didn't actually get changed from my previous review (mentioned as a reply to that review).

Can be one statement.

Should be one line.

Should be review_request, rather than request.

review_requests

Shouldn't be any blank lines before an except: line.

I know this was old code, but can you change it to "please reopen the review request" ?

"No review_request_id"

It's a pretty unlikely situation, but we might want to verify that there's only one exact match before automatically choosing it.

Ship It!