Michael Haggerty

I just created a [v1.2.0 release](https://github.com/mhagger/git-when-merged/releases/tag/v1.2.0) from master. Is that enough to get you started? FWIW I also created a [v1.1.1 release](https://github.com/mhagger/git-when-merged/releases/tag/v1.1.1) containing bugfixes for 1.1.0, not that anybody is...

I'm getting the same error (many times, rolled up in an email from Google most or all days). Except that my inbox only has 58 items in it. My "All...

@mastahyeti: here's the start of the email:  Line 319 in my version of the script (my customization probably changed the line numbers) is ```...

@lbergelson: Aside from setting `.gitattributes` by directory as @technoweenie mentioned, you can also set them based on more specific filename patterns. For example, ``` sim-*.bam filter=lfs -crlf ``` @technoweenie: I'm...

> Though I'm not sure how you'd be able to override this without keeping some `.gitlfsignore` file too. One crowbar is `git commit --no-verify`, which bypasses the `pre-commit` and `commit-msg`...

It's an interesting idea. I don't think I'd want `git-sizer` itself to try to explain possible next steps, since they can be pretty complicated and also have implications like invalidating...

I agree that this would be neat, with one proviso: either we should prove using benchmarks that this feature is not too costly, or we should make it possible to...

Hmmm, good point. We should really supply a test repo explicitly rather than leaning on the `git-sizer` repo, for example by generating it programmatically or in the form of a...

That's a good idea. We'd definitely want a way to distinguish between runtime errors (e.g., repository was corrupt) vs. size "errors"; for example, by returning different exit codes.

This sounds like a good idea. The main question for me is, at what level should it be configured? Let me think out loud about the possibilities, considering not only...