If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler
List of issues
: The issue tracker is now writable again and logged users can download files too. But note that our support is very LIMITED.
#935 Java files in git repository are not eol-normalized
Hi, This is an issue I have with the git repository rather than with the actual decompiler. Not all *.java files in the jpexs github repository are "normalized" and this is giving me a number of issues. With "normalized", I mean normalized as defined in http://git-scm.com/docs/gitattributes: "When a text file is normalized, its line endings are converted to LF in the repository." The .gitattributes files in the jpexs github repository includes the following line for java files: *.java text eol=crlf The "text" attributes controls how eol is stored in the repository and the "eol=crlf" attribute controls how the file is stored in the working directory. The presence of the "text" attributes means that when checking in, "LF" line ending will be used to store the file in the repository. But for some reason it looks like not all the commits perform this conversion to "LF" (e.g. I've seen it in commits made by Honfika). I guess that a git implementation is used that disregards the .gitattributes file (JGit was known to do that, I don't know if it is still the case). The main point is that some java files have crlf-endings (not normalized) in the repository and some java files have lf-endings (normalized). For example the following shows that libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/action/Action.java has crlf line endings in the repo: $ git cat-file -p 1e5ec49df2bb3f8da62a22619d6bae604a593b1f|head -5|grep -U $'\r' This has a special side-effect. Every time i fetch and merge the commits from upstream/master (the original jpexs github repository), "git status" will show me a bunch of files as "modified" in the working directory which are not actually modified: the working directory is expected to be up to date at that point. The files shown as modified correspond with the updated files that are not normalized. Commands like "git checkout -- ." or git reset will not help, the files will always show as being modified because git detects an eol mismatch. Removing the "text" attribute from .gitattributes as hinted at http://git-scm.com/docs/gitattributes restores the "git status" as up to date. This link also states that files should be normalized when using the text attribute: "When text=auto normalization is enabled in an existing repository, any text files containing CRLFs should be normalized. If they are not they will be normalized the next time someone tries to change them, causing unfortunate misattribution." After this long explanation I would like to make the kind request if it would be possible to normalize the files in the repository, i.e. to convert all java files so that they have LF- file endings? Thanks in advance. JB.
Ok, how to do that?
I haven't tried it myself yet, but the link I pointed to previously (http://git-scm.com/docs/gitattributes) suggests the following: $ rm .git/index # Remove the index to force Git to $ git reset # re-scan the working directory $ git status # Show files that will be normalized $ git add -u $ git commit -m "Introduce end-of-line normalization" I omitted the lines with .gitattributes because there is already a .gitattributes file so these steps might not be needed. Since it involves removing the index making a backup of the index file is probably advised.
We will solve this after merging the two branches we currently have (master and v6) which could be relatively soon. Doing this only on master now and later merging the two branches could lead to problems I think (conflict on all lines, etc.) (honfika did the normalization couple hours ago, but we reverted that commit/push for above reasons)
Ok, great. Thanks a lot.
I have merged the v6 branch yesterday evening (I don't know what time was in your place). It should be normalized now in the repository. Check it.
Still having some issues. After fetching and merging the latest upstream/master, "git status" gives me the following: modified: libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/abc/ABCOutputStream.java modified: libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/abc/avm2/parser/pcode/ASM3Parser.java modified: libsrc/ffdec_lib/src/com/jpexs/decompiler/flash/abc/types/ABCException.java modified: src/com/jpexs/decompiler/flash/console/CommandLineArgumentParser.java Looks like these files were not updated by the eol-normalization commit?
No, they were changed by me again... it seems that something is wrong with my git settings or gitattributes file (or probably both of them). I don't have any special Git software (you mentioned JGit)... I have only official git (https://git-scm.com/downloads) and simple netbeans, nothing else. Can you help me to configure my settings?
Netbeans uses JGit internally (JGit is a Java implementation of the original C git). Afaik Netbeans/JGit will ignore the gitattributes files but it can read the global/local config. You can easily check the config using the following command (make sure you are on the master branch when doing this otherwise you will not see the project-specific config from .git/config): "git config -l" Most importance setting is core.autocrlf The optimal setting depends on the operating system you're working on: (https://git-scm.com/book/tr/v2/Customizing-Git-Git-Configuration) for Windows: core.autocrlf=true for Max/linux: coreautocrlf=input I discourage putting this to false. I'm on windows and have core.autocrlf=true core.eol and core.safecrlf are not present in my config files. Hope this info helps.
I changed my autocrlf setting to true. (And changed a lot of files since the config change) Is it ok now?
All looks ok now, after the latest merge: "nothing to commit, working directory clean". Thank you!