Yuki Kokubun <orga.chem.job@xxxxxxxxx> writes: > "git filter-branch -- --all" print unwanted error messages when refs that > cannot be used with ^0 exist. It is not incorrect per-se, but if I were writing this, I'd say "... when refs that point at objects that are not committish" or something like that, as that is much closer to people (both end users and Git developers) than the "^0" implementation detail. > Such refs can be created by "git replace" with > trees or blobs. Also, "git tag" with trees or blobs can create such refs. Taking two paragraphs above together, you wrote an excellent description of the problem to be solved (i.e. what would be seen by users and under what condition the symptom would trigger). If there is a single obvious solution that would trivially follow from the problem description, it is perfectly fine to stop here. Otherwise, it would help to describe how it is solved next. Something as brief like Filter these problematic refs out early, and warn that these refs are left unwritten while doing so. would suffice in this case, I think. We _could_ insert before they are seen by the logic to see which refs have been modified and which have been left intact (which is where the unwanted error messages come from), between "early," and "and warn", if we wanted to. > --- > git-filter-branch.sh | 14 ++++++++++++-- > t/t7003-filter-branch.sh | 14 ++++++++++++++ > 2 files changed, 26 insertions(+), 2 deletions(-) The diff looks good. Please sign-off your patch (cf. Documentation/SubmittingPatches). Thanks.
