On 12/6/06, Liu Yubao <yubao.liu@xxxxxxxxx> wrote:
>> > They problem is the exec-bit which windows does not >> > have and cygwin failed to correctly workaround the >> > limitation. >> > >> > Do a "git repo-config core.filemode false" to almost >> > disable the checks for exec bit. >> > >> >> It has been set. I guess the cause is a interrupted merge >> operation that leads to textual difference. > > yes, though what I can't understand is why don't you have > unmerged entries... Maybe it comes from playing with > all these commands you mentioned in the original mail. > >> After run "git reset --hard", all deleted files come back, but I reach >> the old state: >> $ git status > > When? Immediately after git reset --hard? Then you very > likely have no permission to write (or lost it somehow) into > the working directory, otherwise I don't see could this be > possible. git reset --hard rewrites everything. > Yes, immediately after git reset --hard. I'm sure I have write permission because all deleted files come back and no "permission denied" like message appears.
Maybe you have the files open in some editor? Otherwise something is broken. Could you try current git (I mean something like ba988a83f0cfdafdcfdc7ed44253840ea83578fb?
I will try to run git in debugger, wish I can get the reason.
don't think It'd be as simple as step-by-step in debugger. Try to instrument builtin-read-tree.c or unpack-trees.c and see if it actually updates the files...
$ git merge "sync from origin" HEAD origin Updating 088406b..ff51a98
just for fun, what does following print: git read-tree --reset -u HEAD && git update-index --refresh ? - 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