On Thu, Mar 15, 2018 at 08:42:54AM -0700, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > On Thu, Mar 15, 2018 at 02:03:59PM +0100, Michele Locati wrote: > > > >> Using the --state-branch option allows us to perform incremental filtering. > >> This may lead to having nothing to rewrite in subsequent filtering, so we > >> need > >> a way to recognize this case. > >> So, let's exit with 2 instead of 1 when this "error" occurs. > > > > That sounds like a good feature. It doesn't look like we use "2" for > > anything else currently. > > I do not want to sound overly negative against the first > contribution from a new contributor, but I am not sure if this is a > good idea. While I do agree that the caller of filter-branch would > want _some_ way to tell if the call > > - got some new stuff, > - got no error but did not get anything new, or > - failed > > and act accordingly, changing the exit code to a non-zero value for > the second case above would mean that existing scripts that have > happily been working would suddenly start failing. Due to the lack > of an easy way to tell the first two cases apart, they may have been > doing _extra_ work after calling filter-branch when it found no new > development (resulting in an expensive no-op), or perhaps they > implemented their own way to tell the second case apart from the > first one and efficiently omitting extra work in the second case > already. In either case, these scripts will get broken with this > change.
Hrm. I took the goal to mean that we used to exit with a failing "1" in this case, and now we would switch to a more-specific "2". And I think that matches the behavior of the patch: -test $commits -eq 0 && die "Found nothing to rewrite" +test $commits -eq 0 && die_with_status 2 "Found nothing to rewrite" Am I missing something? -Peff
