git - Git: sistema de control de versiones

Age	Commit message (Collapse)	Author
2010-01-26	tests: consolidate CR removal/addition functions	Stephen Boyd
	append_cr(), remove_cr(), q_to_nul() and q_to_cr() are defined in multiple tests. Consolidate them into test-lib.sh so we can stop redefining them. The use of remove_cr() in t0020 to test for a CR is replaced with a new function has_cr() to accurately reflect what is intended (the output of remove_cr() was being thrown away). Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-09	merge-recursive: respect core.autocrlf when writing out the result	Johannes Schindelin
	The code forgot to convert the blob contents into work tree representation before writing it out. Also fixes leaks -- earlier the updated blobs were never freed. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-09	Add testcase for merging in a CRLF repo	Marius Storm-Olsen
	If you work on a repo with core.autocrlf == true, you would expect every text file to have CRLF EOLs. However, if you by some operation, get a conflict, then the conflicted file has LF EOLs. Now, of course you'd go about resolving the files conflict, and then 'git add <file>'. When you do that, you'll get the warning saying that LF will be replaced by CRLF. Then you commit. The end result is that you have a workingdir with a mix of LF and CRLF files, which after some more operations may trigger a "whole file changed" diff, due to the workingdir file now having LF EOLs. An LF only conflict file results in the resolved file being in LF, the commit is in LF and a warning saying that LF will be replaced by CRLF, and the working dir ends up with a mix of CRLF and LF files. Signed-off-by: Marius Storm-Olsen <marius@trolltech.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>