-
Notifications
You must be signed in to change notification settings - Fork 27
ParsePatchHeader: Copy functionality of git mailinfo's cleanup_subject #17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ParsePatchHeader: Copy functionality of git mailinfo's cleanup_subject #17
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for implementing this and including tests! I had a few style comments and a thought about the API:
One of the goals of this library is to be relatively un-opinionated about how parsed information is presented to clients. To that end, I'd prefer if this cleaning wasn't mandatory (and in fact git am
offers flags to disable it.) My first thought is to define a standalone CleanPatchTitle
function that cleans the title string. Clients could assign the result to the Title
field if they want to persist it.
Another option might be add a RawTitle
field in addition to the Title
field, which now contains the cleaned version. But I think I like the function better: parsed dates used to have a "raw" field and I removed it because it was confusing to use.
I'm also open to other suggestions if you have ideas.
Re the API: I was originally thinking, nobody would ever want to make a commit with Probably the most useful thing to do for the latter case would be to keep whatever we end up deleting from the beginning of the subject line and putting it in another field inside |
Primarily to get rid of [PATCH] at the front, but while we're here just be generally compatible with `git am`: * Remove `re` and variations * Remove whitespace * Remove anything in brackets But only at the very beginning of the subject. Store anything removed in this way in PatchHeader.SubjectPrefix. Inspired by https://github.com/git/git/blob/master/mailinfo.c:cleanup_subject() Signed-off-by: George Dunlap <[email protected]>
74682f1
to
bf196ee
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After thinking about this a bit more, SubjectPrefix
feels like a reasonable approach to solve this. It matches the default behavior of both format-patch
and am
, replicating the function of the -k
flag is easy for clients who want that, and it fits with the contract of PatchHeader
that some fields may be empty after parsing. Thanks again for submitting and updating this.
No prob, thanks for writing the package! Saved me a lot of work. :-) Re API -- I was thinking, since you already have Title and Body broken down, and you have the That's not something I have time to do at the moment, but it's worth thinking about. |
Primarily to get rid of [PATCH] at the front, but while we're here
just be generally compatible with
git am
:re
and variationsBut only at the very beginning of the subject.
Inspired by
https://github.com/git/git/blob/master/mailinfo.c:cleanup_subject()
Signed-off-by: George Dunlap [email protected]
This fixes issue #16