Github Collaboration

why are there 2 constants here?
Fine tuning these settings might not be the best use of your time, given the small audience. Let's document them and move on.

it would be nice to be able to turn on debugging in one place, and boom, verbose logs, strict reporting, etc.
If you're using Zen Cart 1.5.6, verbose logging with backtrace is turned on by default. It's only if you want Notice level logging (that you really don't need), that you need to turn it on.

But again, please feel free to add to the documentation repo with best practice steps, and then you won't have to remember it - you can just check the FAQ.

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:bangin:, the answer is surely no.

@carlwhat can you pitch in here?

swguy:

@carlwhat can you pitch in here?

yes. i can. and i will.

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.

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?

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 :(

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/using-git/configuring-git-to-handle-line-endings#global-settings-for-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.

In Beyond Compare, line endings can be made to be "non-essential" by running a rules based comparison between the file(s). Session->Session Settings->Compare Tab->Compare Contents (section), rules based radio. It doesn't address the "saving" part, though in my git checkout/checkin I think I have set it to always use a particular style, though I haven't reviewed my global settings in a while.

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...

DrByte:

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. :laugh:

DrByte:

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.

Beyond Compare
Session->Session Settings->Compare Tab->Compare Contents (section), rules based radio

Thanks.
Never used that until now. It shows correctly that files are identical. Fast enough for local comparisons...
(I note that there is an additional docs css rule in the ZC157 checkout compared to the release.)

I want this comparison to compare the ongoing ZC158 changes with a reference ZC157 installation and production shop etc.

torvista:

Thanks.
Never used that until now. It shows correctly that files are identical. Fast enough for local comparisons...
(I note that there is an additional docs css rule in the ZC157 checkout compared to the release.)

I want this comparison to compare the ongoing ZC158 changes with a reference ZC157 installation and production shop etc.
In reference to the additional css file, are you comparing the v157 branch to the release or the tagged v1.5.7?

As a side note, versions may have additional files/changes that are not part of the latest release... v156 compared to v1.5.6f is an example... Basically changes "prepped" to support a future sub-release, whether that release occurs or not...

While I understand the emphasis on local as associated to a previous comment, I point out that the comparison works for local to remote or remote to remote as well...

comparing the v157 branch to the release

Yes

Git line endings

turns out it's doing exactly what it's supposed to do: translate to your local machine based on your machine's configuration.
Yes, I got that. But is it not doing that based on the .gitattributes of the fileset, not the machine configuration?

My scenario is

1. my new shop starts with a sourceforge fileset: unix endings.
2. I merge my mods in from the current production shop, taking care to convert these to unix endings.
3. over time, new things appear in Github v158 that I may want to merge in too: but these checkout automatically converted to Windows endings as per the .gitattributes "* text=auto" that is in the github fileset. So any file I want to merge, I'll have to convert manually.

So if I want to stop Git checkout converting the checkout to windows endings, I suppose I need to change the gitattributes "* text command....but if it is part of the fileset, how can I do that/override it?