On Thu, Mar 15, 2018 at 03:57:15PM +0100, Michele Locati wrote: > >> git-filter-branch.sh | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > > This should probably get a mention in the manpage at > > Documentation/git-filter-branch.txt, too. > > Yes, I agree it would be useful. What about this addition right after the > "Remap to ancestor" section? > > EXIT CODE > --------- That seems like a good place (for those just reading on the list, it's right before the "examples" section). It looks like we don't have many similar sections, but when we do we call them "EXIT STATUS" (which seems to match other projects like "grep"). > In general, this command will fail with an exit status of `1` in case of errors. > When the filter can't fine anything to rewrite, the exit status is `2`. s/fine/find/ Do we want to commit to status `1` for everything else? Most of the C code that dies does so with 128, and I wonder if that could propagate in some cases. IOW, could we leave room for that and for future changes with something like: On success, the exit status is `0`. If the filter can't find any commits to rewrite, the exit status is `2`. On any other error, the exit status may be any other non-zero value. -Peff PS I think this is your first patch to Git. I forgot to say: welcome to the list!
