This is great! The only thing I'm curious about is whether people might be confused by the unchecked portion and not being able to do anything about it.

The only thing I'm curious about is whether people might be confused by the unchecked portion and not being able to do anything about it.

We could use the commit form to provide more context:

Maybe an ⚠️ icon above the button alongside a message like Untracked files excluded from rebase when they're in this situation? I can noodle on how this would look if this feels on the right track.

Tested the functionality and LGTM.

Dropping ready-to-review while I implement this suggested change #7377 (comment)

Maybe an ⚠️ icon above the button alongside a message like Untracked files excluded from rebase when they're in this situation? I can noodle on how this would look if this feels on the right track.

The ⚠️icon might feel like there's an issue that a user needs to fix in order to move on (like a merge conflict.) Maybe using an ℹ️icon or something to visually associate it more closer to the file it's referencing (for example, like the diff-added octicon):

Another consideration is to hide the checkboxes for all files since it seems like we wouldn't want users to interact with the list at all.

@donokuda that's a good shout - I'll try it out!

Another consideration is to hide the checkboxes for all files since it seems like we wouldn't want users to interact with the list at all.

I worry about removing the checkboxes because their state is still helpful to indicate what will be rebased and what will be skipped, and for any unexpected side-effects in the DOM (we've not tried this before).

Thoughts on going even more minimal and starting off with no octicon and putting the text below the button? After looking at my original proposal again, I'm not really sold on how it visually looks with the added icon.

If we find out that it's confusing to a lot of people, we can go back to the drawing board.

I worry about removing the checkboxes because their state is still helpful to indicate what will be rebased and what will be skipped, and for any unexpected side-effects in the DOM (we've not tried this before).

Makes sense, I'd rather keep this as simple as possible than adding more scope without realizing the consequences of it.

I'm a big fan of minimal, especially since my concern might be completely unfounded and people will just be like, "yeah, of course it works that way."

@donokuda I dig the mininalism. Let me push some changes to this branch and get a working demo together...

Latest screenshots - warning when there are untracked files:

After removing the untracked change, the warning goes away:

@shiftkey Looks good! Is it "Uncommitted" or "Untracked"? I assume you've got it right - just making sure.

The last item on my list is what to do with the context menu that is shown:

My current thinking on this is that, when in the middle of a rebase conflict, these options should only be enabled:

We could also show "Discard Changes" if the file is untracked, as a convenient way to address the warning.

I need to do some internals refactoring to be able to change this behaviour, but let me know if you have suggestions about the list to show in this state.

Is it "Uncommitted" or "Untracked"? I assume you've got it right - just making sure.

@billygriffin "Uncommitted" is too vague for my liking in this situation. Git has two terms which are more explicit:

• "Unstaged file" - changes to a tracked that have not been added to the index
• "Untracked file" - a new files in the repository which is not yet tracked by Git

That's why I've settled on "Untracked" here...

EDIT: I meant to use Untracked in the UI, but didn't notice. 🤦‍♂️

Here's the context menu entries for a tracked file in the middle of a rebase:

And here's what you see for an untracked file:

Tested and functionally working 👍

We could also show "Discard Changes" if the file is untracked, as a convenient way to address the warning.

Did catch one thing:
The right-click on the n files changed still shows the Discard All Changes option.

3e3c288, mac

Holding off on final review until we decide if https://github.com/desktop/desktop/pulls?q=is%3Aopen+is%3Apr+no%3Aassignee+label%3Aready-for-review#issuecomment-485977147 should be addressed in this PR.

The right-click on the n files changed still shows the Discard All Changes option.

Nice find @tierninho. I feel bad for hiding it away, given how not discoverable it is. There's some extra context here that I'll write up into a fresh issue in the morning before I do disable it.

There's some extra context here that I'll write up into a fresh issue in the morning before I do disable it.

#7394

Merged without updating since doing so would have been the 4th time.