Duy Nguyen <pclouds@xxxxxxxxx> writes: > On Tue, Jan 29, 2013 at 7:31 PM, Matthieu Moy > <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: >> I like the idea. >> >> Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: >> >>> diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh >>> index b3f6eb9..096ba6f 100755 >>> --- a/t/t7512-status-help.sh >>> +++ b/t/t7512-status-help.sh >>> @@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before resolving conflicts' >>> test_must_fail git rebase HEAD^ --onto HEAD^^ && >>> cat >expected <<-\EOF && >>> # Not currently on any branch. >>> - # You are currently rebasing. >>> + # You are currently rebasing '\''rebase_conflicts'\''. >> >> Perhaps "rebasing *branch* 'rebase_conflicts'" > > Looks good. One minor thing, if the ref happens to be > refs/somewhere-not-in-heads, should we still say "rebasing branch > 'refs/...'" or just "rebasing 'refs/...'", or something else? I think this should not happen, since HEAD can either point to a branch or directly to a sha1 in normal conditions. But it doesn't harm to be defensive, in case ... >> Or even "rebasing branch 'rebase_conflicts' on <sha1sum>" > > <sha1sum> being SHA-1 of HEAD? Not HEAD, but .git/rebase-merge/onto, i.e. the target of the rebase. Ideally, I would have loved to see "rebasing master on origin/master", but I do not think the target ref name is stored during rebase. > Why would you need it? The typical use-case is starting a rebase, do something else, come back the day after and wonder wft. Which branch is being rebased is probably the most useful, but the target may help too. But I can live without ;-). > In short version, not full SHA-1? If you add it, the short one (long version would make overly long line with limited use). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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