Duy Nguyen <pclo...@gmail.com> writes:

> On Tue, Jan 29, 2013 at 7:31 PM, Matthieu Moy
> <matthieu....@grenoble-inp.fr> wrote:
>> I like the idea.
>> Nguyễn Thái Ngọc Duy <pclo...@gmail.com> 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
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

Reply via email to