gemmellr commented on PR #6034: URL: https://github.com/apache/activemq-artemis/pull/6034#issuecomment-3502463696
> I should have mentioned a couple more things. >The assembly changes were enough to fix the build in my case. > >So the .gitattributes file isn't needed to cover this specific case I was dealing with. >While looking into it though, it still made sense to me to include those options (default, *.cmd and binaries, in case git itself doesn't see a file as a binary). A weird case here are .pem files, which i believe have mixed line endings(?). I did see a point in adding this file, but I'm also not opposed to dropping it. I think we keep it simple and avoid adding it. We've never had it, and most repos dont seem to use it. The issue mainly only came up because you had what would be considered a very unusual if not flat out incorrect setting...and even then that mainly only got noticed because the assembly left it floating, when it makes sense for it not to. Changing that alone seems like the appropriate fix. >About the git index - not 100% sure what's happening ... There must be a default case of normalizing to LF somewhere like you say. >I was trying to override LF with CRLF with the help of .gitattributes and running renormalize, or changing the endings myself/commiting a new file with CRLF. >Running renormalize correctly updated those .java files that had CRLF line endings, with 0 issues. > >Running ls-files --eol correctly sets the *.cmd "attributes" to CRLF, but I never managed to update the index ... I expected the .gitattribute file would be enough. I also played around with autocrlf, tried it on both windows and linux, and tried re-cloning the repo to see if the situation would be different. Yes, the git index normalises to LF usually...but especially with .gitattributes text config set: https://git-scm.com/docs/gitattributes > text > >This attribute marks the path as a text file, which enables end-of-line conversion: When a matching file is added to the index, the file’s line endings are normalized to LF in the index. Conversely, when the file is copied from the index to the working directory, its line endings may be converted from LF to CRLF depending on the eol attribute, the Git config, and the platform (see explanation of eol below). In short, they should normally be LF in the index, the 5 that aren't just now were probably added on a linux box and so didnt normalize to LF in the index as they dont have fixed attributes and were going against the normal grain of the LF in the checkout. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
