Zoltan Klinger <zoltan.klin...@gmail.com> writes:
> When a rebase is interrupted by a merge conflict it could be useful to
> know how far a rebase has progressed and how many commits in total this
> rebase will apply. Teach the __git_ps1() command to display the number
> of commits so far applied and the total number of commits to be applied.
> Below is a sample output of the improved __git_ps1() command:
> In the example above the rebase has stopped at the second commit due to
> a merge conflict and there are a total number of five commits to be
> applied by this rebase.
> This information can be alredy obtained from the following files which are
> being generated during the rebase:
> GIT_DIR/.git/rebase-merge/msgnum (git-rebase--merge.sh)
> GIT_DIR/.git/rebase-merge/end (git-rebase--merge.sh)
> GIT_DIR/.git/rebase-apply/next (git-am.sh)
> GIT_DIR/.git/rebase-apply/last (git-am.sh)
> 1) Modify git-rebase--interactive.sh to also create
> files for the number of commits so far applied and the total number of
> commits to be applied.
> 2) Modify git-prompt.sh to read and display info from the above files
> 3) Update test t9903-bash-prompt.sh to reflect changes introduced by
> this patch.
> Signed-off-by: Zoltan Klinger <zoltan.klin...@gmail.com>
Nicely explained. Felipe? Szeder? Comments?
> contrib/completion/git-prompt.sh | 21 ++++++++++++++++-----
> git-rebase--interactive.sh | 5 +++++
> t/t9903-bash-prompt.sh | 6 +++---
> 3 files changed, 24 insertions(+), 8 deletions(-)
> - printf " (b1|REBASE-i)" > expected
> + printf " (b1|REBASE-i|1/1)" > expected
This makes me wonder if " (b1|REBASE-i 1/1)" may be easier on the
eyes. Also it may not be a bad idea to add a new piece to this test
to show the state that is not "1/1" but something else.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html