On Thu, Jul 30, 2015 at 12:59 PM, Matthieu Moy
<Matthieu.Moy@xxxxxxxxxxxxxxx> wrote:
> Karthik Nayak <karthik.188@xxxxxxxxx> writes:
>
> Solving this doesn't seem much harder than
>
> diff --git a/ref-filter.c b/ref-filter.c
> index 6c0189f..a4df287 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -1117,7 +1117,7 @@ static int ref_filter_handler(const char *refname, const struct object_id *oid,
> struct commit *commit = NULL;
> unsigned int kind;
>
> - if (flag & REF_BAD_NAME) {
> + if (!filter->show_bad_name_refs && (flag & REF_BAD_NAME)) {
> warning("ignoring ref with broken name %s", refname);
> return 0;
> }
> diff --git a/ref-filter.h b/ref-filter.h
> index 98ebd3b..b9d2bbc 100644
> --- a/ref-filter.h
> +++ b/ref-filter.h
> @@ -79,7 +79,7 @@ struct ref_filter {
> match_as_path : 1;
> unsigned int lines, branch_kind;
> int abbrev, verbose;
> - int detached : 1;
> + int detached : 1, show_bad_name_refs : 1;
> };
>
> struct ref_filter_cbdata {
>
> and setting filter->show_bad_name_refs when needed (untested). Did I
> miss something?
>
This allows it to be added to ref_array. But it would still fail while
trying to obtain
object details prior to printing.
> IIRC, historicaly Git allowed some weirdly named refs which made some
> commands ambiguous (e.g. a branch named after an option like '-d').
> We're forbidding their creation so people shouldn't have any, but we
> it's important to continue showing them in case some people have old
> bad-named branches lying around.
>
> I'd rather have the code strictly better after your contribution than
> before.
>
Agreed. But then again the warning tells about the broken ref, as in it's name
So I think It's ok?
for e.g. t1430 :
[trash directory.t1430-bad-ref-name] ../../git branch
warning: ignoring ref with broken name refs/heads/broken...ref
* master
--
Regards,
Karthik Nayak
--
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