Re: [RFC/PATCH v2] create a skeleton for the command git rebase --status

[Junio C Hamano <gitster@pobox.com>]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> 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'.