Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > But I think there are more relevant information to show (e.g. list of > already applied commits, remaining list of commits, possibly truncated > if the list is overly long, and information that rebase gave you when > stopping like the path to the file being applied). Having them all in > "git status" would make the output really long, for little benefit in > day-to-day use. Sorry, I do not quite agree with this reasoning. Isn't "git status" during a rebase that shows "really long" information to help the rebase operation a good thing? In day-to-day use when you are not in the middle of rebase, the command would not show what remains to be done, would it? I may be biased, because I rarely use 'git status' while running 'git rebase' (with or without interactive). But to me, 'git diff' would be a more appropriate tool to help me unstuck in managing the current step of conflict resolution than 'git status' gives me during either a rebase or a merge as "Unmerged paths" anyway. If this topic enhances 'git status' with the in-progress rebase information, I'd view it as turning 'git status' from 'a more or less useless command during rebase' to 'a useful command'. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html