Tim's last commit

[kybos]

Hi Tim,

I have merge conflicts with your last commit in my branch and git refuses to merge them or even to display a sensible diff. I looked at your commit and noticed that most of the code was completely deleted and then recreated, at least according to git. Do you know what went wrong here?

65060d1

Edit:
It seems that for some files the code was not changed at all (ctrledit.cpp, ctrlcanvas.cpp) - why are they in the commit at all?

[terminator356]

Oops, I see what happened:
I was working on unrelated Windows stuff and I changed KDevelop's
End Of Line setting from UNIX to DOS/Windows.
Thus any MusE file I touched since 06/25 has had all the end-of-lines changed from CR to CR/LF.
This includes for example ChangeLog, structure.cpp, and any other files I touched.
They were changed wholesale, as seen in the commits!

Beyond that, after my changes of 6/29 Robert found an issue with a variable/function I had
named 'minor' causing interference with some system names or something, so he changed that.

Not sure why all of this would mess up any merges or diffs.
Is there a way out of this for you?

I will change my end-of-line setting back to UNIX and try to remember to re-touch
all the files I changed, the next time I commit.
Unless... maybe it's a good idea to make all files' end-of-lines DOS/Windows?
Thinking of Windows ports here... Might help editors working on that platform?

[kybos]

I solved my problem after I had noticed that the files I needed were not really modified in your commit.

But you see in the commit already that git can do no diff for these files, because for git it's new code. So changing EOLs everywhere would probably mean destroying all the git history IMO. There are probably options to ignore the different EOLs in git and other tools, but it's obviously not the default.
After all, MusE is mainly a Linux program, isn't it? Changing the EOL format to DOS does not sound very logical.
And even in Windows every advanced text editor can read and write UNIX EOLs (which are LF, by the way, not CR - that is Mac).
It's quite incredible that KDevelop does things like that without even warning you. I thought serious text editors recognize the format automatically and keep it, unless you change it explicitly. When there is a default setting for EOL, it should only be relevant for new files.

[terminator356]

Well, it was Delphi code, and the IDEs in this case, Lazarus and old BCB4, did not like UNIX style.
I was contributing to a library where the developer had (accidentally?) changed all the
recent files to UNIX style, so I had to change them back to DOS style.

It's not KDevelop's fault, I told it to do that, and it only modifies a file if you touch it, which I did.
Sorry about that. Forgot to switch it back.

And yeah, I mixed up that CR/LF thing, I sometimes forget that it's LF on UNIX ;-)