On Sun, May 03, 2020 at 09:55:39AM -0700, Junio C Hamano wrote:
> >> Does that seem reasonable?
> >
> > FWIW, I think that is the best direction. If anybody is depending on the
> > "commit-graph write will complain about non-commits" behavior, they
> > could only be doing so for a few versions; prior to v2.24.0 we did not.
>
> If we had it for the past 180 days or so, that's not like " people
> have seen it for only a brief time", but working it around shouldn't
> be too difficult---they need to validate the input they feed to the
> command themselves (or do they need to do more?).
Yeah, my point wasn't so much that it was brief as that we've had it
both ways, and nobody was complaining about it before v2.24.0 (the
type-restriction change came as a side effect of another tightening).
But yeah, if somebody really wants that validation, they can do it
themselves with "cat-file --batch-check". Or even for-each-ref directly:
git for-each-ref --format='%(objectname) %(objecttype) %(*objecttype)' |
awk '/commit/ { print $1 }' |
git commit-graph write --stdin-commits
If you're using --stdin-commits, you're presumably processing the input
anyway (since otherwise you'd just be using --reachable).
I suppose you could argue the other way, too (that the user could be
filtering out non-commits). But so far we have one data point in either
direction, and it wants the more forgiving behavior. :)
-Peff
