>> "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. I agree that readability to users is important than the implementation detail. So, I'm gonna change the commit message. >> 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. I think the detailed description is better than the shorter one in this case. So I'm gonna follow to detailed one.
