In addition to the previous post I made also check the commands / instructions out below. Once the files are initially committed you may have a hard time getting git to deal with the new line ending commit setup due to previously committed files. (If you follow these instructions I recommend taking your local files and backing them up [just in case])
git add . -u
git commit -m "Saving files before refreshing line endings"
# Save your current work so that it's not lost.
git rm --cached -r .
# Remove everything from the index.
git reset --hard
# Write both the index and working directory from Git's database.
git add .
# Prepare to make a commit by staging all the files that will get normalized.
# This is your chance to inspect which files were never normalized. You should
# get lots of messages like: "warning: CRLF will be replaced by LF in file."
git commit -m "Normalize all the line endings"
nopCommerce 3.40 roadmap and estimated release date. Let's discuss.
Team Member
- 16619
- 155940
- 10/22/2008
- Armenia
cybernexus wrote:
I've already tried this solution. But it cause some other issues (e.g. Git started treating some DLLs and other binary files as TEXT ones and replacing LF with CRLF in them when downloading).
You may know that when you're installing Git for Windows you can choose one of three options (see screenshot here - http://downloads.nopcommerce.com/share/git-install.png). The first option (default for Windows) causes all these issues (I presume 99% of developers have it chosen). The last one works just great ("core.autocrlf" set to "false"). But as you may know it's a computer specific. We cannot make people to install or configure Git as we need. It should be repository specific (only for nopCommerce). So we know that this setting ("core.autocrlf" set to "false") works just great. We know that nopCommerce works only on Windows (no need to support *nix systems). Does anybody know if we can set "core.autocrlf" to "false" only for a specific repository?
If there's no such setting or config, then maybe, the previously suggested solution can be "adjusted" or "polished" somehow to support it (without described issues)?
...
I've already tried this solution. But it cause some other issues (e.g. Git started treating some DLLs and other binary files as TEXT ones and replacing LF with CRLF in them when downloading).
You may know that when you're installing Git for Windows you can choose one of three options (see screenshot here - http://downloads.nopcommerce.com/share/git-install.png). The first option (default for Windows) causes all these issues (I presume 99% of developers have it chosen). The last one works just great ("core.autocrlf" set to "false"). But as you may know it's a computer specific. We cannot make people to install or configure Git as we need. It should be repository specific (only for nopCommerce). So we know that this setting ("core.autocrlf" set to "false") works just great. We know that nopCommerce works only on Windows (no need to support *nix systems). Does anybody know if we can set "core.autocrlf" to "false" only for a specific repository?
If there's no such setting or config, then maybe, the previously suggested solution can be "adjusted" or "polished" somehow to support it (without described issues)?
- 55
- 667
- 8/19/2010
- United States
a.m. wrote:
I've been storing my nopcomemrce projects in git for quite a while now without any of the described issues. I am going to look over my projects and see what may be different, if I find anything I will let you know.
...
I've already tried this solution. But it cause some other issues (e.g. Git started treating some DLLs and other binary files as TEXT ones and replacing LF with CRLF in them when downloading).
You may know that when you're installing Git for Windows you can choose one of three options (see screenshot here - http://downloads.nopcommerce.com/share/git-install.png). The first option (default for Windows) causes all these issues (I presume 99% of developers have it chosen). The last one works just great ("core.autocrlf" set to "false"). But as you may know it's a computer specific. We cannot make people to install or configure Git as we need. It should be repository specific (only for nopCommerce). So we know that this setting ("core.autocrlf" set to "false") works just great. We know that nopCommerce works only on Windows (no need to support *nix systems). Does anybody know if we can set "core.autocrlf" to "false" only for a specific repository?
If there's no such setting or config, then maybe, the previously suggested solution can be "adjusted" or "polished" somehow to support it (without described issues)?
I've already tried this solution. But it cause some other issues (e.g. Git started treating some DLLs and other binary files as TEXT ones and replacing LF with CRLF in them when downloading).
You may know that when you're installing Git for Windows you can choose one of three options (see screenshot here - http://downloads.nopcommerce.com/share/git-install.png). The first option (default for Windows) causes all these issues (I presume 99% of developers have it chosen). The last one works just great ("core.autocrlf" set to "false"). But as you may know it's a computer specific. We cannot make people to install or configure Git as we need. It should be repository specific (only for nopCommerce). So we know that this setting ("core.autocrlf" set to "false") works just great. We know that nopCommerce works only on Windows (no need to support *nix systems). Does anybody know if we can set "core.autocrlf" to "false" only for a specific repository?
If there's no such setting or config, then maybe, the previously suggested solution can be "adjusted" or "polished" somehow to support it (without described issues)?
I've been storing my nopcomemrce projects in git for quite a while now without any of the described issues. I am going to look over my projects and see what may be different, if I find anything I will let you know.
- 297
- 2733
- 6/16/2011
- Vietnam
Load all locale resources on startup:
Load all localized properties on startup:
Load all search engine friendly names on startup:
these options would consume a huge amount of RAM as there's tons of data from it. I know that Nop makes too many server calls just for these tiny localized info and add some overhead on the performance.
What about using Web Storage on client browser ? Allowing these info stored on client pc, and only retrieve them from Javascript. Unlike cookies, it allows 5mb or more
Browser supported: IE 8+ and all other browsers.
http://www.html5rocks.com/en/features/storage
http://code.msdn.microsoft.com/Working-with-HTML5-local-b0cbe2ef
http://www.c-sharpcorner.com/UploadFile/18ddf7/html5-web-storage/
http://www.codeguru.com/csharp/.net/two-ways-of-passing-html5-web-storage-data-to-asp.net.htm
http://www.w3schools.com/html/html5_webstorage.asp
Load all localized properties on startup:
Load all search engine friendly names on startup:
these options would consume a huge amount of RAM as there's tons of data from it. I know that Nop makes too many server calls just for these tiny localized info and add some overhead on the performance.
What about using Web Storage on client browser ? Allowing these info stored on client pc, and only retrieve them from Javascript. Unlike cookies, it allows 5mb or more
Browser supported: IE 8+ and all other browsers.
http://www.html5rocks.com/en/features/storage
http://code.msdn.microsoft.com/Working-with-HTML5-local-b0cbe2ef
http://www.c-sharpcorner.com/UploadFile/18ddf7/html5-web-storage/
http://www.codeguru.com/csharp/.net/two-ways-of-passing-html5-web-storage-data-to-asp.net.htm
http://www.w3schools.com/html/html5_webstorage.asp
- 78
- 964
- 3/26/2010
- United Kingdom
a.m. wrote:
I use GIT Extensions with VS 2012 and have a GIT repo on CodePlex.
I have also selected the first 'Line endings' option: 'Checkout Windows-style, commit Unix-style line endings ("core.autocrlf is set to "true").
I added a .gitattributes file to the root of the repo. The file contains the following to control line endings for a specific file. I'm not sure if you can set per folder/contents or project wide.
# Prevent conversion from UNIX EOL format /r to MS-DOS EOL format /r/n
taxonomy.txt text eol=lf
...
I've already tried this solution. But it cause some other issues (e.g. Git started treating some DLLs and other binary files as TEXT ones and replacing LF with CRLF in them when downloading).
If there's no such setting or config, then maybe, the previously suggested solution can be "adjusted" or "polished" somehow to support it (without described issues)?
I've already tried this solution. But it cause some other issues (e.g. Git started treating some DLLs and other binary files as TEXT ones and replacing LF with CRLF in them when downloading).
If there's no such setting or config, then maybe, the previously suggested solution can be "adjusted" or "polished" somehow to support it (without described issues)?
I use GIT Extensions with VS 2012 and have a GIT repo on CodePlex.
I have also selected the first 'Line endings' option: 'Checkout Windows-style, commit Unix-style line endings ("core.autocrlf is set to "true").
I added a .gitattributes file to the root of the repo. The file contains the following to control line endings for a specific file. I'm not sure if you can set per folder/contents or project wide.
# Prevent conversion from UNIX EOL format /r to MS-DOS EOL format /r/n
taxonomy.txt text eol=lf
- 7
- 325
- 6/10/2014
- Spain
Now that you are migrating to Git (great news!) it may be a good time to change the source branching model to something like it is used in Orchard (https://orchard.codeplex.com/SourceControl/latest) so it is easier to contribute, and to deploy minor versions and patches more frequently.
3.x - for the actual development version (now 3.40)
3.30.x - for patches and small fixes in the last relased version
feature/feature_name - for new features
We are currently using this working flow quite sucessfully.
Regards,
Richard
3.x - for the actual development version (now 3.40)
3.30.x - for patches and small fixes in the last relased version
feature/feature_name - for new features
We are currently using this working flow quite sucessfully.
Regards,
Richard
- 21
- 145
- 4/23/2014
- United States
a.m. wrote:
The above suggestions comes from this post. If it is changing binary files you need to make sure that those file types are marked as binary in the gitattributes.
...
I've already tried this solution. But it cause some other issues (e.g. Git started treating some DLLs and other binary files as TEXT ones and replacing LF with CRLF in them when downloading).
I've already tried this solution. But it cause some other issues (e.g. Git started treating some DLLs and other binary files as TEXT ones and replacing LF with CRLF in them when downloading).
The above suggestions comes from this post. If it is changing binary files you need to make sure that those file types are marked as binary in the gitattributes.
Team Member
- 16619
- 155940
- 10/22/2008
- Armenia
johndillon wrote:
Currently it's planned to be done in 3.40 but we cannot guarantee it for sure
johndillon wrote:
Please see the original post of this topic - July 2014 (middle of July, most probably)
Can I ask if https://nopcommerce.codeplex.com/workitem/9291 is going to be part of 3.4?
Currently it's planned to be done in 3.40 but we cannot guarantee it for sure
johndillon wrote:
If so do we have an estimated release date for 3.4?
Please see the original post of this topic - July 2014 (middle of July, most probably)
- 148
- 1108
- 2/8/2013
- United Kingdom
a.m. wrote:
OK thanks, really appreciate your help.
1. Roughly how likely is it it will be done? Its essential to a project Im working on so I need to make a call whether or not we do this ourselves.
2. Presumably we are talking about a pretty complicated change here? I ask this to help assess whether or not we just do this ourselves.
Thanks again
Can I ask if https://nopcommerce.codeplex.com/workitem/9291 is going to be part of 3.4?
Currently it's planned to be done in 3.40 but we cannot guarantee it for sure
If so do we have an estimated release date for 3.4?
Please see the original post of this topic - July 2014 (middle of July, most probably)
Currently it's planned to be done in 3.40 but we cannot guarantee it for sure
If so do we have an estimated release date for 3.4?
Please see the original post of this topic - July 2014 (middle of July, most probably)
OK thanks, really appreciate your help.
1. Roughly how likely is it it will be done? Its essential to a project Im working on so I need to make a call whether or not we do this ourselves.
2. Presumably we are talking about a pretty complicated change here? I ask this to help assess whether or not we just do this ourselves.
Thanks again