If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler
NEW : We have got a new blog where we post some interesting SWF internals info.

#935 Java files in git repository are not eol-normalized
Author:
JackB

Date created:
Type: question
Visibility: Everybody
Assigned to:
Labels: LineEndings
State: closed 

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.
State: new→upgraded
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!
State: upgraded→closed