4 ms·
I do appreciate the attention to detail. Fortunately, even if "G" were appended to the commit message, grep would fail to match (and remove) it: a tab is output
by mikegerwitz 14y ago
I do appreciate the attention to detail. Fortunately, even if "G" were appended to the commit message, grep would fail to match (and remove) it: a tab is output directly before %G? (which, as you mentioned, could be an empty string). This ensures that there will always be characters after the subject.
That said, it could be terribly confusing when viewing the output. For that reason, perhaps another character after the tab (before the %G?) would be a good addition.
- Natsu 14y agoIs there no way to sneak a tab into the message?
- mikegerwitz 14y agoIndeed there is, but there will always be a tab after that tab. Consider this commit message: Foo\tG This would result in the following output: ... Foo\tG\t
- Natsu 14y agoOk, that makes more sense. It's hard to see whitespace, so I didn't notice a tab lurking just before the newline.
- Natsu 14y agoWait... if I can sneak a tab in there, what if someone hid a newline in there, too? Would you not end up with foo\tG \t And break the regex? Or is there absolutely no way to smuggle a \n into the message?
- mikegerwitz 14y ago%s inserts the "subject", not the entire commit message. The subject is considered to be the first line of the commit message (I forget if there is a character limit), so a newline would simply be considered the delimiter (and would not appear in the output). Otherwise, you would be correct --- that would have rendered the check useless.
- Natsu 14y agoAhh, you're right. I get a little paranoid when dealing with user-supplied strings, but usually that's a good thing :)
- mikegerwitz 14y agoAbsolutely; your critical thought and inquiry is a very positive thing.