Thanks for the speedy reply. > Only the long option --ignore-commit works with your patch, -I doesn't. > Correct. I took that out because I didn't want to use "-I' which could eventually be used by a more commonly used feature. Do you agree or do you think it is worth using it. It's a UI decision I didn't want to make. > > This function was moved from below, but it seems to be indented with > three spaces instead of tabs now. Adding a declaration without moving > the function would avoid that and result in a smaller patch. > Good catch, I'll do that and re-send. > > An ignored commit can still be blamed if there is no other commit to > pass it on. So e.g. the initial commit for the file could end up being > blamed for lines that were added by later commits which are being > ignored. That may look confusing. > > Would it make sense to pass the blame to some kind of null commit, i.e. > a special marker that says "I could tell you who is to blame for this > line but you said you don't want to know"? > A null commit could work. I think the behavior should be to not ignore the commit. Meaning if you specify a commit that introduced a line of code that line of code will still be blamed on the ignored commit. Does That sound logical or is it too confusing? Thanks, Dylan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html