Asked  7 Months ago    Answers:  5   Viewed   15 times

In trying to standardise the platform for the developers, one of my needs would be to commit the .git/config so that everybody have the same CRLF config without forgetting to set it by hand.

How do I set this up?

I'm a bit concerned by all this negativity against autocrlf. Why not remove this feature if it doesn't work? Either the makers of this feature are misunderstood or they made a failed experiment with it and it should be removed to stop more people from wasting their time (reading the obscure man page, asking questions, people answering those questions etc.).

 Answers

35

I have always found the autocrlf config property problematic. (as expressed in my answer Git 1.6.4 beta on Windows (msysgit) - Unix or DOS line termination)

  • it not only make some merges tricky
  • it can vary depending on the shell used within one environment
  • it also has issue with git status
  • and with svn import.

Note: msysgit issue 538 for setting it to true (which is the default value set by the msysgit installer), but I am not convinced.

I would prefer one of the three following solutions for:

  • configuring one end-of-line style
  • making that configuration propagate through the different Git repos

First: git config --global core.autocrlf false
Then:

1. Using the new config setting core.eol (1.7.2+)

Sets the line ending type to use in the working directory for files that have the text property set.
Alternatives are 'lf', 'crlf' and 'native', which uses the platform's native line ending.
The default value is native.

2. a checkout/checking .gitattribute. See gitattributes man page: crlf or core.autocrlf is the way to record in a .gitattributes file what is was previously a local config attribute.

You can add checkout/checkin attributes like:

*.vcproj    text eol=crlf
*.sh        text eol=lf

3. a git attribute filter driver which can:

  • enforce any kind of formatting standard you may want to set
  • apply those standards to certain files/directories
  • be recorded as a config file (.gitattributes) able to be pushed anywhere.
Tuesday, June 1, 2021
 
TuomasR
answered 7 Months ago
93

No you cannot force a file that is already committed in the repo to be removed just because it is added to the .gitignore

You have to git rm --cached to remove the files that you don't want in the repo. ( --cached since you probably want to keep the local copy but remove from the repo. ) So if you want to remove all the exe's from your repo do

git rm --cached /*.exe

(Note that the asterisk * is quoted from the shell - this lets git, and not the shell, expand the pathnames of files and subdirectories)

Tuesday, June 1, 2021
 
Slinky
answered 7 Months ago
19

If you tell git to ignore a directory, it will completely ignore everything inside that directory. This means git cannot match your exclude because git is simply not looking at it.

The only way to use excludes in a meaningful way is for a single directory, where you ignore everything but some folder like this:

/some/path/*
!/some/path/foo

This will ignore all entries but foo directly under /some/path.

But, most of the time it is much clearer to just explicitly ignore things than using excludes.

Thursday, August 19, 2021
 
Scott Kausler
answered 4 Months ago
18

I finally figured it out after many hours of debugging, and I somehow knew there was a simple issue with the configuration.

Since the second guide mention how to set up gitlab on apache with a relative url you actually have to do some more configs inside gitlab. I uncommented the line about relative url:s unicorn.rb and in gitlab-shell/config I added my whole URL (with subdirectory).

Before:

 http://web-adress.com/

after:

 http://web-adress.com/subdomain/

Now it works great.

Wednesday, September 22, 2021
 
Ula
answered 3 Months ago
Ula
65

It's important to note that this system referenced in question was built from source code and supported nginx was replaced with Apache (not officially supported by gitlab).
Here is the deal - in the standard nginx config on my system I can see this

upstream gitlab-workhorse {
  server unix:/var/opt/gitlab/gitlab-workhorse/socket;
}

proxy_pass http://gitlab-workhorse;

Which means - it's using socket. Not a network port. If I try to see if the workhorse even listening on network - I will see that it's not.

ps -ef|grep -i workhorse
lsof -p pid

Would not show any network ports open by workhorse pid. So perhaps apache config is incorrect? It should be using socket instead of port?

Wednesday, December 1, 2021
 
Michal Charemza
answered 1 Day ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :
 
Share