Thread (3 messages) flat view 3 messages, 2 authors, 2018-03-24

Re: [PATCH] filter-branch: consider refs can refer to an object other than commit or tag

From: Yuki Kokubun <hidden>
Date: 2018-03-24 19:34:01

Possibly related (same subject, not in this thread)

quoted
"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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help