Yuki Kokubun <orga.chem....@gmail.com> 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.
