2010/1/20 Junio C Hamano <gitster@xxxxxxxxx>:
> Jeff King <peff@xxxxxxxx> writes:
>
>> Could be a bad interaction between commits on nd/sparse and whatever was
>> done since it had branched. You can try rebasing nd/sparse and bisecting
>> a linearised version, like this:
>>
>> bad_merge=73d66323
>> # pretend we are on nd/sparse
>> git checkout -b test $bad_merge^2
>> # rebase onto what we merged onto
>> git rebase $bad_merge^1
>
> That is a very good suggestion.
>
> You will get hit by a few conflicts during the rebase, but I managed to
> arrive at the same tree as $bad_merge after running the rebase procedure
> above. Just for Jonathan's convenience, the result is at:
>
> git://repo.or.cz/alt-git.git junk-linearized-nd-sparse-for-bisection
>
> I'll remove this after a few days.
>
>> # now bisect. what we have now is presumably
>> # bad (though you should probably double check)
>> # and from the previous bisect we know that
>> # everything pre-merge is good
>> git bisect start
>> git bisect good $bad_merge^1
>> git bisect bad
>
> It would be interesting to hear the result of the test in the particular
> repository Jonathan is seeing the problem with. The issue didn't
> reproduce for me, either but I only tried "having a staged change" case
> without any more detailed set-up.
>
OK, found some more interesting results from that. The new bad commit is :
commit 66dce7bdb6742cb06433f8ef25441690b71c7995
Author: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
Date: Thu Aug 20 20:47:01 2009 +0700
Read .gitignore from index if it is skip-worktree
I still haven't been able to come up with a minimal test case, but gdb
gave me this:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000000001c8
0x0000000100093e69 in excluded_1 (pathname=0x7fff5fbfd8b0
"shared/config/environments/.gitignore", pathlen=37,
basename=0x7fff5fbfd8cb ".gitignore", dtype=0x7fff5fbfd8a4,
el=0x7fff5fbfeb00) at dir.c:378
378 if (*exclude == '/')
(gdb) bt
#0 0x0000000100093e69 in excluded_1 (pathname=0x7fff5fbfd8b0
"shared/config/environments/.gitignore", pathlen=37,
basename=0x7fff5fbfd8cb ".gitignore", dtype=0x7fff5fbfd8a4,
el=0x7fff5fbfeb00) at dir.c:378
#1 0x0000000100093fd0 in excluded (dir=0x7fff5fbfeac0,
pathname=0x7fff5fbfd8b0 "shared/config/environments/.gitignore",
dtype_p=0x7fff5fbfd8a4) at dir.c:410
#2 0x0000000100094a10 in read_directory_recursive
(dir=0x7fff5fbfeac0, base=0x7fff5fbfdd20
"shared/config/environments/", baselen=27, check_only=0, simplify=0x0)
at dir.c:688
#3 0x0000000100094bfa in read_directory_recursive
(dir=0x7fff5fbfeac0, base=0x7fff5fbfe190 "shared/config/", baselen=14,
check_only=0, simplify=0x0) at dir.c:727
#4 0x0000000100094bfa in read_directory_recursive
(dir=0x7fff5fbfeac0, base=0x7fff5fbfe600 "shared/", baselen=7,
check_only=0, simplify=0x0) at dir.c:727
#5 0x0000000100094bfa in read_directory_recursive
(dir=0x7fff5fbfeac0, base=0x1000f48d0 "", baselen=0, check_only=0,
simplify=0x0) at dir.c:727
#6 0x0000000100094ecc in read_directory (dir=0x7fff5fbfeac0,
path=0x1000f48d0 "", len=0, pathspec=0x0) at dir.c:813
#7 0x0000000100093118 in fill_directory (dir=0x7fff5fbfeac0,
pathspec=0x0) at dir.c:70
#8 0x00000001000e85a7 in wt_status_collect_untracked
(s=0x7fff5fbfef80) at wt-status.c:346
#9 0x00000001000e86cc in wt_status_collect (s=0x7fff5fbfef80) at
wt-status.c:366
#10 0x000000010001e467 in cmd_status (argc=0, argv=0x7fff5fbff248,
prefix=0x0) at builtin-commit.c:1026
#11 0x0000000100001b52 in run_builtin (p=0x10013e3b0, argc=1,
argv=0x7fff5fbff248) at git.c:257
#12 0x0000000100001d04 in handle_internal_command (argc=1,
argv=0x7fff5fbff248) at git.c:401
#13 0x0000000100001e83 in main (argc=1, argv=0x7fff5fbff248) at git.c:482
"shared/config/environments/.gitignore" contained just
"_local_config.rb", no newline. It seemed like adding or removing
characters from that file would 'fix' the problem, but changing them
wouldn't (ie the problem was always there when .gitignore was 16
bytes), but I'm not entirely sure because it continues to be a bit of
a Schrodinger bug.
One thing I wondered about from that commit - shouldn't the "buf =
xmalloc(size);" on dir.c:252 be "buf = xmalloc(size+1);" ? I haven't
really looked at the program flow there, so may be wrong...
--
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