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
> In short version, not full SHA-1?
If you add it, the short one (long version would make overly long line
with limited use).
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