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.
Created attachment 142628 [details] Conflicts during checkout Switching a branch back to master fails. All code committed and pushed, nothing to Revert or Resolve, yet the dialogue comes up for it. Commit dialogue really is empty stating there's nothing to commit. Going for (unnecessary) Revert or Resolve fails, see attached screenshot.
What is the output of 'git status' in commandline? Any local modifications? What is the value of core.autocrlf config variable (either in .git/config or inside the user-wide .gitconfig somewhere in userdir)? This is an issue of a 3rd-party client we're using, can you please prepare a test repository where this happens and attach it here?
And please attach the messages.log with the error for start.
Unfortunately I already cloned clean, but will dive into the details of the failure if I come across it again. If the bug is there, it'll surface.
It has something to do with line-endings and sometimes happens on Windows or on Mac when the line-ending are different in the working tree (CR, CRLF) than in the repository (usually LF). I am unable to reproduce on Linux, i can only guess this is the reason. Do you mix NetBeans Git support with any external client (commandline git client)?
I've had that sense too, sometimes it doesn't show a diff line, but the change is seemingly there. I had an impression I'm working with UNIX linebreaks, have to double-check. I'm not mixing the Git client or using it on the command-line, but I recall from earlier times that the native Git client sometimes gives a different result on the console. I'll try to reproduce and report back.
I was playing a bit on Windows and found the case when this happens: 1) you must have core.autocrlf=true/input set either in global .gitconfig or in the local repository's .git/config file - this setting ensures transformations from CRLF to LF when committing and vice-versa when checking out so in the repository there will always be only files with LF encoding (unix-like). 2) someone does not play by these rules and commits into repository a file with different encoding => so when cloning this repository you get: A) in the working tree a file with CRLF line-endings B) in the index (and repository) the file has also CRLF (or CR) line-endings this case results in JGit (Java git client we're using) having problems. I cannot fix this unfortunately but at least i'm adding some logging. There are some options you can take: 1) always commit with \n line-endings 2) when this happens, fix the line-endings in the repository 3) do not use autocrlf (resp. add core.autocrlf=false into your .git/config file) If this is not your case, please make a simple test case repository, attach it here and reopen. Thanks. fixed: core-main #009dc9ab1d02
i think this may help solve the problem: https://git.eclipse.org/r/#/c/19397/ When the patch gets into JGit and eventually JGit is upgraded in NB, it should work.