On 12/6/06, Liu Yubao <yubao.liu@gmail.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Dec 06 23:31:10 2006
This archive was generated by hypermail 2.1.8 : 2006-12-06 23:33:51 EST