This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version = NetBeans IDE Dev (Build 201103310400) Operating System = Windows Vista version 6.0 running on x86 Java; VM; Vendor = 1.6.0_24 Runtime = Java HotSpot(TM) Client VM 19.1-b02 Git Version: 0.2.10 Doing a merge there are confilcts and I choosed to resolve them. But Merge Conflicts Resolver only lets me choose either one version of the file. I expected to get a diff where i accept lines from one version and other lines from the vesion. nothing meaning full to me in the log: INFO [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater]: Complete indexing of 0 binary roots took: 0 ms INFO [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater]: Complete indexing of 0 source roots took: 0 ms (New or modified files: 0, Deleted files: 0) [Adding listeners took: 0 ms]
I do understand our Conflicts Resolver is not very user-friendly, it's an archaic piece of code and i agree it deserves to be rewritten to suit modern needs. If you need to resolve a conflict in a more complex way i am afraid you'll need to open the file in editor and resolve it manually or use some external resolving tool.
To make it a it clearer. I was working with the Conflicts Resolver and svn before and it was OK. Parts of the file which were the same in both versions were white and the differences where colored (red and green i think). One could choose to accept this block from the left side and that from the right till all conflicts were solved. Here with Git I had two file versions which were 95% identical but both sides were red so i could either accept the left or right side as a whole. Because I knew it was working with NB 6.9 and svn, I thought the problem was within the Git plugin.
Created attachment 107514 [details] file in conflict
Created attachment 107515 [details] conflicts resolver
I don't know, all seems to work, see my attachments. The file got in conflict after a merge and the resolver correctly displays the differing areas. To analyze your problem i would need to see your file with conflict markers, can you send it to my email?
(In reply to comment #5) > I don't know, all seems to work, see my attachments. The file got in conflict > after a merge and the resolver correctly displays the differing areas. > To analyze your problem i would need to see your file with conflict markers, > can you send it to my email? I've send you a screen shot and the file with conflicts to the netbeans.org address. Don't know what conflict markers are, but hope that was what you wanted.
Created attachment 107770 [details] snapshot while attempt to merge got this again and could reproduce it while doing a snapshot still no clue why it goes wrong sometimes all i did was a simple fetch and merge
I tried to merge the one revision from your repo with another locally modified but had no problem (on Windows, too). I guess it's some kind of Windows specific issue, i noticed several files being listed as modified although there was no content modification. However they seemed to differ (against current head) in some file attributes (as executable bit etc.). Maybe that's the problem, JGit might not be able to compare contents if the file attributes differ and just claims the whole file is different. I'll investigate further and try to find a repro case.
checked the file attributes, they don't look any different than other files. Noticed when I 'Review' the problems (instead 'Resolve' conflicts) the file has the status 'Both Modified' but the file wasn't modified before the merge.
> Noticed when I 'Review' the problems (instead 'Resolve' conflicts) the file has > the status 'Both Modified' but the file wasn't modified before the merge. Both modified does not mean 'modified in working tree' but the fact that a file 'was modified in both branches', that's why you get the merge conflict. For more see 'git help status', section OUTPUT/merge conflicts
The best way to fix this or at least to realize what's going on would be to create a simple git test case repository where this problem occurs. Try to create a local repo, add the incriminated file, create to branches, make some changes to that file and try a merge. If you're able to get such a repo, attach it here.
Probably caused by core.autocrlf set to true. Please try with core.autocrlf property set to false: edit .git/config and add autocrlf=false under the core section