Re: New feature discussion: git rebase --status
- From
Thomas Rast <trast@inf.ethz.ch>
- Date
- Jun 11, 2013, 12:40 UTC
- Message-ID
- <871u8895xh.fsf@linux-k42r.v.cablecom.net>
- In-Reply-To
- <fb379a75c6c1af6dcff2e65bef1f1836@ensibm.imag.fr>
Mathieu Liénard--Mayor <mathieu.lienard--mayor@ensimag.fr> writes:
Show 31 quoted lines
> (Got the idea from: > https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_rebase_--status) > > When in the middle of a rebase, users can be easily confused about > what to do, or where they are in the rebase process. > > All the information is available in .git/rebase-merge/, but I believe > it would be helpful to have a command (for example 'git rebase > --status') which would explicitely indicate the state of the process. > > For instance, the output could look like: > > $ git rebase --status > Rebasing my_last_commit onto base_commit > Already applied 2 patches: > b170635... my_commit_message > b170635... my_commit_message > Currently applying b170635... my_commit_message > 2 patches left to apply: > b170635... my_commit_message > b170635... my_commit_message > > > Another nice thing could be to improve the output of 'git status' by > saying the number of patches left to apply. > As an example, it could say: > You are currently rebasing (patch 3/5). > > What do you think? > Does the name rebase --status seem appropriate? > Should the output be providing more/less information?
I think a worthy goal would be to arrange things such that the "here's what you do next" messages are shared between --status and the code that stops. I.e., the same code should generate
When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort".
in both cases. Naturally --status should also explain how it got into this state, as you outlined above.
--
Thomas Rast
trast@{inf,student}.ethz.ch