LGTM, however I spotted two issues:

• the Push menu item is still active in the Repo menu, which triggers a console error:
  Uncaught (in promise) Error: The current repository is in a detached HEAD state
  

• Aside from above and while in this state, if you navigate to the Changes tab and uncheck the changes, the Continue rebase button is still active. I expect to be be disabled until the user checks the changed file(s).
  

the Push menu item is still active in the Repo menu, which triggers a console error:
Uncaught (in promise) Error: The current repository is in a detached HEAD state

This is a good find. I assumed that the menu items were aware of a detached HEAD but I'll see if I can lock that down for 1.6.3.

• Aside from above and while in this state, if you navigate to the Changes tab and uncheck the changes, the Continue rebase button is still active. I expect to be be disabled until the user checks the changed file(s).

This is an interesting point, and I've got some ideas to tackle this:

• make the Continue Rebase button aware of the included files count
• make the files which are part of the rebase checked and disable the checkbox, so the user cannot uncheck them while in the middle of a rebase

I favour the latter approach because the app should require the user to bring along all the files when continuing the rebase. @billygriffin any objections to figuring out how to achieve that within the Changes tab?

Make the files which are part of the rebase checked and disable the checkbox, so the user cannot uncheck them while in the middle of a rebase

I also favor the latter.

(strike previous comment)

make the files which are part of the rebase checked and disable the checkbox, so the user cannot uncheck them while in the middle of a rebase

Makes sense to me, agreed! One question, I remember there was some goofiness in the merge conflicts flow around working directory changes being inadvertently committed as part of the conflict resolution process. Does that same concern exist in this flow or no?

@billygriffin

One question, I remember there was some goofiness in the merge conflicts flow around working directory changes being inadvertently committed as part of the conflict resolution process. Does that same concern exist in this flow or no?

Are you referring to untracked files and this issue #6411? If so, I have the same behaviour in place when continuing a rebase:

For tracked changes, there's two different flows to consider:

• starting a rebase - the current behaviour is to either block you with a message, or enable rebase.autostash as I talked about in Option to rebase instead of automatically merge when pulling from upstream #3422 (comment)

• continuing a rebase - if you make a change to another file as part of resolving conflicts, this will be included in the commit when continuing the rebase. This might be a bit confusing at first listen, but it's the same behaviour as when you rebase via the Git command line (it won't let you continue without staging all changes).

Happy to chat more about this if there's further questions. I've also opened #7006 to track what we should do with the checkboxes for changed files while in a rebase.

@shiftkey I believe @billygriffin is referring to #6349 (but correct me if i'm wrong)

Since #7005 and #7006 are now a thing, I think I'm comfortable with this.