Hi Simo,
Simo Melenius wrote:
> I noticed this because "git branch -a" and "git branch -av"
> unexpectedly gave a very different output.
Hmm --- so the error message must not have been very visible...
> When listing branches, "git branch" will in certain cases terminate
> iteration at the first broken ref that doesn't point to a commit.
Even in a broken repository, the full branch list would be useful for
getting one’s bearings. Thanks.
> commit = lookup_commit_reference_gently(sha1, 1);
> if (!commit)
> - return error("branch '%s' does not point at a
> commit", refname);
> + {
> + error("branch '%s' does not point at a
> commit", refname);
> + return 0;
> + }
Will this make ‘git branch’ exit with status zero? Scripts and people
with fancy prompts benefit from a nonzero exit status.
If I have 37 branches and an error is encountered looking up one of
them, with this patch the error message will scroll off the screen.
Is this worth worrying about? It depends on what the usual causes for
broken branch refs are and whether they require attention or can be
safely ignored.
One other thought: this patch is line-wrapped, which means it cannot
be mechanically applied. Documentation/SubmittingPatches has some
tips on sending a patch unmangled (and please also see the section
labelled "Sign your work").
Cheers,
Jonathan
--
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