Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This part bothers me:

git log --pretty="format:%H$t%aN$t%s$t%G?" "${chkafter:-HEAD}" --first-parent \ | grep -v "${t}G$"

What of the case where some smartass decides to

$ git commit -am 'Yet another foo G'

So long as it doesn't have a bad signature, it will give an empty string, right? So how do I know where the G came from?



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.


Is there no way to sneak a tab into the message?


Indeed 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


Ok, that makes more sense. It's hard to see whitespace, so I didn't notice a tab lurking just before the newline.


Wait... 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?


%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.


Ahh, you're right. I get a little paranoid when dealing with user-supplied strings, but usually that's a good thing :)


Absolutely; your critical thought and inquiry is a very positive thing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: