Re: [TESTCASE] Failing 'git am' when core.autocrlf=true

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Thu, 23 Aug 2007, Marius Storm-Olsen wrote:
> 
> I have an issue with git-rebase failing on a repository using
>     core.autocrlf=true
> 
> I've tracked it down to git-am failing with core.autocrlf=true and passing
> with core.autocrlf=false. I've tried digging deeper into the code, but for
> some reason ce_match_stat_basic() (read-cache.c:~187) reports the size of the
> file in the index to be 0 (when core.autocrlf=true), which is why git-am bails
> out on the patch. (ce->ce_size == 0, while st->st_size == the correct size on
> disk)

Very interesting.

Adding some instrumentation to "git-am.sh" (namely a lot of

	git diff --quiet || exit

lines to figure out exactly *where* the index gets out of sync with the 
working tree), I get this trace:

	trace: built-in: git 'mailsplit' '-d4' '-o.dotest' '-b' '--'
	trace: built-in: git 'diff-index' '--cached' '--name-only' 'HEAD'
	trace: built-in: git 'diff' '--quiet'
	trace: built-in: git 'mailinfo' '-u' '.dotest/msg' '.dotest/patch'
	trace: built-in: git 'stripspace'
	trace: built-in: git 'diff' '--quiet'
	trace: built-in: git 'apply' '--allow-binary-replacement' '--index' '.dotest/patch'
	trace: built-in: git 'diff' '--quiet'
	trace: built-in: git 'diff' '--quiet'
	trace: built-in: git 'write-tree'
	trace: built-in: git 'diff' '--quiet'

ie everything was fine after the "apply" phase, but the index and the 
working tree went out-of-kilter after "git write-tree".

The reason? "git write-tree" doesn't read the config file, so it never 
even reads the "core.autocrlf=true" variable. As a result, it seems to 
screw up the index matching when it does the cache_tree_fully_valid() 
(which will fail due to "git apply --index" having invalidated the tree 
SHA1's) followed by cache_tree_update().

> Can anyone please enlighten me on why this may happen?

This patch should fix it. 

Junio - it fixes the test for me, but quite frankly, I don't see why 
write-tree would *ever* change any non-tree index entries. But it does. I 
think there's another bug somewhere, or I'm missing something.

		Linus

---
 builtin-write-tree.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/builtin-write-tree.c b/builtin-write-tree.c
index 88f34ba..b89d02e 100644
--- a/builtin-write-tree.c
+++ b/builtin-write-tree.c
@@ -72,6 +72,7 @@ int cmd_write_tree(int argc, const char **argv, const char *unused_prefix)
 	const char *prefix = NULL;
 	unsigned char sha1[20];
 
+	git_config(git_default_config);
 	while (1 < argc) {
 		const char *arg = argv[1];
 		if (!strcmp(arg, "--missing-ok"))
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux