tgif.git - Terin's Improved Git Fork

Age	Commit message (Collapse)	Author	Files	Lines
2008-05-27	t5100: Avoid filename "nul"	Junio C Hamano	1	-2/+2
	There are broken filesystems that cannot have a file whose name is "nul" anywhere on it. Rename the test file to make ourselves more portable. Noticed by Mark Levedahl. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25	mailinfo: apply the same fix not to lose NULs in BASE64 and QP codepaths	Junio C Hamano	1	-0/+9
	Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25	mailsplit and mailinfo: gracefully handle NUL characters	Johannes Schindelin	1	-0/+9
	The function fgets() has a big problem with NUL characters: it reads them, but nobody will know if the NUL comes from the file stream, or was appended at the end of the line. So implement a custom read_line_with_nul() function. Noticed by Tommy Thorn. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-15	mailinfo: feed only one line to handle_filter() for QP input	Jay Soffian	1	-1/+1
	The function is intended to be fed one logical line at a time to inspect, but a QP encoded raw input line can have more than one lines, just like BASE64 encoded one. Quoting LF as =0A may be unusual but RFC2045 allows it. The issue was noticed and fixed by Jay Soffian. JC added a test to protect the fix from regressing later. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02	Rewrite "git-frotz" to "git frotz"	Junio C Hamano	1	-3/+3
	This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-03-12	Add a couple more test cases to the suite.	Don Zickus	1	-1/+1
	They handle cases where there is no attached patch. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-27	mailinfo: do not get confused with logical lines that are too long.	Linus Torvalds	1	-1/+1
	It basically considers all the continuation lines to be lines of their own, and if the total line is bigger than what we can fit in it, we just truncate the result rather than stop in the middle and then get confused when we try to parse the "next" line (which is just the remainder of the first line). [jc: added test, and tightened boundary a bit per list discussion.] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-17	t5100: mailinfo and mailsplit tests.	Junio C Hamano	1	-0/+28
	Currently the test passes with 1.3.3 but not with the tip of "master". This is to verify the fixes from Eric W Biedermann. Signed-off-by: Junio C Hamano <junkio@cox.net>