Duy Nguyen pclo...@gmail.com writes:
Point taken. I guess the message would be something like this?
Refname '%.*s' is ignored. It may be created by mistake.
Or should we be more elaborate?
I dunno; with s/may be/may have been/, I think it is better than
refname is ambiguous.
--
To
On Mon, May 20, 2013 at 11:17 PM, Junio C Hamano gits...@pobox.com wrote:
Think why the user has such a hard to type ref in the first place.
The user may have done this previously, thinking that he is detaching
the HEAD to fix an earlier mistake in a branch:
$ BAD_COMMIT=$(git rev-parse
Thomas Rast tr...@inf.ethz.ch writes:
Junio C Hamano gits...@pobox.com writes:
In addition to your topic, it may be a good idea to notice this at
the Porcelain level (e.g. checkout -b and branch, but not at the
update-ref level) and warn or even die if a Porcelain tries to
create a branch
Duy Nguyen pclo...@gmail.com writes:
On Thu, May 16, 2013 at 6:42 AM, Junio C Hamano gits...@pobox.com wrote:
* nd/warn-ambiguous-object-name (2013-05-07) 1 commit
- get_sha1: improve ambiguity warning regarding SHA-1 and ref names
git cmd name, when name happens to be a 40-hex string,
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We are past -rc2 and haven't seen any regression reported since the
feature freeze started, which may be a good sign (the coming release
is
On Wed, May 15, 2013 at 4:42 PM, Junio C Hamano gits...@pobox.com wrote:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We are past -rc2 and haven't seen any regression reported since
6 matches
Mail list logo
