[codeface] Re: Line endings issues

  • From: Mitchell Joblin <joblin.m@xxxxxxxxx>
  • To: Andreas Ringlstetter <andreas.ringlstetter@xxxxxxxxxxxxxxxxxxxx>
  • Date: Wed, 21 Oct 2015 17:41:49 +0200

On Wed, Oct 21, 2015 at 5:01 PM, Andreas Ringlstetter
<andreas.ringlstetter@xxxxxxxxxxxxxxxxxxxx> wrote:



Am 21.10.2015 um 16:51 schrieb Mitchell Joblin:
On Wed, Oct 21, 2015 at 2:59 PM, Andreas Ringlstetter
<andreas.ringlstetter@xxxxxxxxxxxxxxxxxxxx> wrote:


Am 21.10.2015 um 14:34 schrieb Mitchell Joblin:
Hi all,

I seem to have never ending misery with the file line endings. There
are odd consequences the end up causing Codeface to fail because
trying to execute the file results in "file not found" even though its
in the directory (e.g. this occurred for the persons.r file). Also git
add has weird behavior, it simply will not allow some files to be
staged. What is the strategy to handle this issue once and for all? I
can look more deeply into this issue myself but whoever made the
change may wish to voice their more informed opinion regarding the
appropriate solution.

Run the following with a clean staging area and workspace:

$ rm .git/index
$ git reset
$ git add -u
$ git commit -s -m"Fix line endings in existing files"

That fixes all line endings not conforming with the settings specified
in .gitattributes in your local branches or codebase.

Ok, no I am certain that this did _not_ fix the problem. I again had
the issue that trying to execute scripts returns "no such file or
directory" I then executed the dos2unix utility and then it will run.
Here is shell output.

Is the solution to run dos2unix on all files and commit the changes?

mitchell@joblin:~/workspace/codeface/codeface/R/ml$ ls
analysis.r batch.r download.r error.dump.rda init.response.r
keyword.list.r ml_utils.r project.spec.r Rplots.pdf
test_analysis.r test_data thread.info.r twomode.r
mitchell@joblin:~/workspace/codeface/codeface/R/ml$ ./download.r
: No such file or directory
mitchell@joblin:~/workspace/codeface/codeface/R/ml$ find ./ -type f
-exec dos2unix {} \;
dos2unix: converting file ./test_data/gmane.comp.emulators.qemu.mbox
to Unix format ...
dos2unix: converting file ./init.response.r to Unix format ...
dos2unix: converting file ./analysis.r to Unix format ...
dos2unix: converting file ./ml_utils.r to Unix format ...
dos2unix: converting file ./thread.info.r to Unix format ...
dos2unix: converting file ./test_analysis.r to Unix format ...
dos2unix: Binary symbol 0x16 found at line 32
dos2unix: Skipping binary file ./Rplots.pdf
dos2unix: converting file ./.gitignore to Unix format ...
dos2unix: converting file ./keyword.list.r to Unix format ...
dos2unix: converting file ./.Rhistory to Unix format ...
dos2unix: Binary symbol 0x1F found at line 1
dos2unix: Skipping binary file ./.RData
dos2unix: converting file ./project.spec.r to Unix format ...
dos2unix: Binary symbol 0x1F found at line 1
dos2unix: Skipping binary file ./error.dump.rda
dos2unix: converting file ./download.r to Unix format ...
dos2unix: converting file ./twomode.r to Unix format ...
dos2unix: converting file ./batch.r to Unix format ...
mitchell@joblin:~/workspace/codeface/codeface/R/ml$ ./download.r
Usage: ./download.r <ml> <start date> <mbox>

That's not making any sense to me now. What's the output of

$ git config core.autocrlf

for you?

yes, returns input.

--Mitchell


It should be "input", everything else will screw your workspace. That's
the default setting on any Unixoid system with git.

Kind regards,

Mitchell



This should only be necessary on copies cloned and files added prior to
the addition of the .gitattributes file. The cause is an outdated index
file, deleting it followed by a `git reset` rebuilds it.

Greetings,
Andreas Ringlstetter

Thanks,

Mitchell

On Tue, Oct 13, 2015 at 2:37 PM, Wolfgang Mauerer
<wolfgang.mauerer@xxxxxxxxxxxxxxxxx> wrote:
Am 13/10/2015 um 14:29 schrieb Mitchell Joblin:
On Tue, Oct 13, 2015 at 2:21 PM, Wolfgang Mauerer
<wolfgang.mauerer@xxxxxxxxxxxxxxxxx> wrote:
Hi Mitchell,

Am 13/10/2015 um 14:16 schrieb Mitchell Joblin:
Hi all,

I am not really sure what is going on with the edits to this patch but
maybe its related to the line endings issues. Git basically does allow
you to do anything until these changes are commited.

Has anyone else had this happen?

does the Java patch still apply properly after you have modified
it with this patch? (I.e., does the patched patch still work)?

I didn't try. I have never applied that patches before. It looks like
I need to install some more packages before I can apply them. At least
that path doesn't exist on my installation yet. I can try to test that
later.

to clarify: I was not asking if the b4j library still works after
applying the patch, only if the patch applies correctly with the
sanitised line endings. IIRC, the b4j sources use a mix of different
line endings, or at least this patch introduces a mix.

Since the bug tracking analysis is not actively being used right
now and is anyway being rewritten ATM, the question is if we should

a) get rid of the patches completely (in this case, we can also get
rid of the current version of the bug tracking analysis, because
it won't then anyway anymore)
b) turn of the CRLF conversion for these files, and keep them around
until a better bug tracker parser is merged.
c) fix the patch files so that they apply cleanly, but do not cause
crlf conversion issues.

Any opinions?

Thanks, Wolfgang

--Mitchell


Thanks, Wolfgang


Kind regards,

Mitchell






Other related posts: