Matthieu Moy <matthieu....@grenoble-inp.fr> writes: > More precisely: if we find such a branch ref and we're used with an > option that requires us to lookup the commit, then we report it as an > error. > ... > So I agree with Junio that the commit message is not sufficient: there > is a behavioral change. I'm OK with it, but the commit message shouldn't > claim that there isn't. > > Porting to ref-filter drops the commit before we get an opportunity to > complain, so we stop complaining because it's not worth the trouble.
I share the same conclusion. It may be an unfortunate fallout but giving the diagnosis was not really the job for this codepath in the first place. If it were, then I would have said we should fix it to keep the behaviour, even if the fix is involved, and that is why I would not necessarily agree with "not worth the trouble". > BTW, this looks like an fsck bug: > > $ git fsck --strict > Checking object directories: 100% (256/256), done. > error: refs/heads/broken: not a commit > $ echo $? > 0 Interesting. Perhaps leave it as a MicroProject for GSoC next year? ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
