| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Create `git_email_*` which will encapsulate email creation and application, and `git_email_create_from_commit` in particular, which creates an email for a single commit.
Introduce a function to create an email from a diff and multiple inputs about the source of the diff. Creating an email from a diff requires many more inputs, and should be discouraged in favor of building directly from a commit, and is thus in the `sys` namespace.
Allow a `0` patch index and `0` patch count; in this case, simply don't display these in the email.
Move the `git_diff_commit_as_email` function to use `email_create`.
Introduce `git_email__append_from_diff` so that we don't always overwrite the input buffer.
`git format-patch` includes binary diffs by default when creating emails. Match this behavior.
`git format-patch` includes diffs with rename detection enabled by default when creating emails. Match this behavior.
`git_diff_format_email` is deprecated in favor of `git_email_create`.
| Back | FazBrowse Home | New Git URL |
This does some refactoring on the git_diff_format_email functionality to address some minor issues. Since these are breaking changes, it introduces git_email_create with the changes. (I expect that there will be a future git_email_apply that mirrors git am.)
The differences are:
git_diff_format_email can take a git_buf an append to it across subsequent calls. (Behavior which is, in fact, codified in a test.) This behavior is uncommon (possibly unique to git_diff_format_email). git_email_create always clears the buffer before placing data into it.
Much of the data in the options structure is, in fact, not optional. Non-optional arguments are now just arguments.
Per (1), I expect to introduce a git_email_create_from_commits or _from_revspec that produces a series of emails to provide a similar behavior to format_email (based on feedback).