Github Collaboration

[torvista]

Can you update the documentation page

...after an afternoon of pain with hugo, git, "permission denied", ssh-windows and three kids climbing the walls after three weeks in anti-quarantine, the answer is surely no.

[swguy]

@carlwhat can you pitch in here?

[carlwhat]

@carlwhat can you pitch in here?

yes. i can. and i will.

[carlwhat]

i am trying to find my documentation repo on my local machine and update it. if i have to recreate it, it may be a bit.

i have other things i am working on.

documentation always seems to be the last thing on any project. although i am a fan of the process as well as encouragement.

thanks for your patience.

best.

[torvista]

So, downloading ZC157 from sourceforge and also checking out branch ZC157 with a Git client, should result in an identical comparison.

On Windows, with Beyond Compare, it shows that the files from Sourceforge have unix line endings, and the ones from Git have Windows line endings and so there are many "differences" indicated....with no actual code differences.

I imagine the git client converts unix-windows on checkout and converts back windows-unix on commit.

So, how to stop that so the git checkout is unix and all compares the same?
A setting in the gitattributes I believe...but this is part of the checkout files....so what can be done to force the checkout to stay as unix/make the compare identical?

[DrByte]

The zip on sourceforge was built by doing a fresh git checkout, on my Mac.
Your git checkout was done on your computer, apparently Windows.
Your git client is converting all the line-endings to windows-style, and mine to linux style.

The .gitattributes setting is pretty standard: "* text=auto" ... which is what I see in most other repositories I work with, where people are using various OS's.

I don't really have a definitive answer for Windows.

Now with 1.5.7 released today maybe now is a good time to experiment with tweaking your git client configuration and eventually end up with a new more compatible directory?

That said, zcwilt and I will be chatting about re-normalizing all files in 1.5.8. If we do it, be prepared for a massive number of changed files ... which upgraders will hate

[DrByte]

Upon further digging, turns out it's doing exactly what it's supposed to do: translate to your local machine based on your machine's configuration.

For Windows: https://help.github.com/en/github/us...r-line-endings

$ git config --global core.autocrlf true
# Configure Git to ensure line endings in files you checkout are correct for Windows.
# For compatibility, line endings are converted to Unix style when you commit files.

[carlwhat]

i will say that administration/housekeeping tends to be the bane of my existence. and the handling of line feeds tends to fall into that category.

i am not sure why you would want to or care why the sourceforge download is different from the git checkout; but hey we all have our reasons. i would think all of the compare programs have a setting to ignore the line endings, but i can not say for sure.

i know at times on the github repo, it seems that files have linux line endings except for the lines inserted by the stamper witch have windows line endings.... perhaps, it is me and my config. i will look a bit more closely. but for me low priority...

zcwilt and I will be chatting about re-normalizing all files in 1.5.8. If we do it, be prepared for a massive number of changed files ... which upgraders will hate

and as far as normalizing files; as long as they have unix line endings, and contributors do not have to conform to one spec for existing files and another spec for new(er/ish) files, that would be great. considering any number of contributors all use phpStorm for their IDE, it might be advantageous to put in the docs the exact settings that one can use to conform to the new normalized files. i know one upgrader that will not say "boo" about the normalizing.

[swguy]

That said, zcwilt and I will be chatting about re-normalizing all files. If we do it, be prepared for a massive number of changed files ... which upgraders will hate

Using the Linux tool diff with the option -w will only show non-whitespace differences. Using this utility, you can build the changed file list and only show files that have changed by more than whitespace.