Intellij with git - Contents have differences only in line separators - java

I've just installed IntelliJ IDEA with git and pulled down code from the framework. Immediately after doing this, I get hundreds (out of thousands) of files saying that 'contents have differences only in line separators'. If I change these from CRLF to LF it makes no difference. Any idea how to fix this?

One possible reason may be change of line separator style after your checkout, and a missed git reset after that. For example, if you change global config "core.autocrlf" or ".gitattributes" file, you may need to reset git index.
Backup your changes and execute those commands at the root of git repository to reset git index:
rm .git/index
git reset

Related

Git manage environment specific configuration

I have a requirement to have a property configuration for different environment like dev, uat and production. For example a config.properties having and entry like environment=dev, this I need to change for staging branch as environment=uat and for master branch as environment=prd .
I tried to commit these files in each branch respectively and tried adding config.properties in gitignore so that it will not consider in next commits.
But git ignore not getting updated so I ran command
git rm -rf --cached src/config.properties
git add src/config.properties
git commit -m ".gitignore fix"
But this command is deleting the file from local repository itself and the proceeding commits also deleting from branches. I want to handle the branch as such so as Jenkins will do the deployment without editing config file manually. I am using fork for git UI. Is there any way to handle this kind of situation?
You should not version a config.properties (git rm is right), and ignore it indeed.
That way, it won't pose any issue during merge.
It is easier to have three separate files, one per environment:
config.properties.dev
config.properties.uat
config.properties.prd
In each branch, you would then generate config.properties, with the right value in it, from one of those files, depending on the current execution environment.
Since you have separate branches per environment, with the right file in it, you can have a generation script which will determine the name of the checked out branch with:
branch=$(git rev-parse --symbolic --abbrev-ref HEAD)
That means you could:
version only a template file config.properties.<env>
version value files named after the branches: config.properties.dev, config.properties.uat...: since they are different, there is no merge issue when merging or switching branches.
Finally, you would register (in a .gitattributes declaration) a content filter driver.
(image from "Customizing Git - Git Attributes", from "Pro Git book")
The smudge script, associated to the template file (package.json.tpl), would generate (automatically, on git checkout) the actual config.properties file by looking values in the right config.properties.<env> value file.
The generated actual config.properties file remains ignored (by the .gitignore).
See a complete example at "git smudge/clean filter between branches".

Unstaged changes in Eclipse, but no changes in git

When i change something in my repository.I see some "Unstaged Changes" in Eclipse, but when i use git at the same time, it tells me that there is no any updates in my repository.
Why is that?
Should i change or configure something to see changes at the same time?
Or it's something normal?
It happens to me many times,
apparently there is a bug on git client in Eclipse
What do i do, and helped me:
Try to stage the files and then unstage them via Eclipse
after that those files disappear form the unstaged area in Eclipse.
This can happen if any of the files are inadvertently checked in with a character case inconsistencies in the path.
You might need to do something like:
git mv Path/file.c path/file.c

Intellij - Git status shows files have been changed when they have not

I am working on a Java project in Intellij that uses git. Quite a few files are blue (to show that changes have been made), however when I right click them and click on "Git -> Compare with Latest Repository Version" it says that the contents are identical. Anyone know why this happens? It only seems to happen to files that I've opened to look at but haven't changed. Could it happen if I accidentally added extra white space and then deleted it or something? Or just extra whitespace in general?
This is how GIT is different from SVN. GIT's change detection algorithm does not depend only on the content of the file but the meta data (timestamp last modified, etc) of the file as well. So even if you are adding just one space and removing it later on; if you save it, it modifies the metadata of the file.
For more details, you can have a look at: What algorithm does git use to detect changes on your working tree?

When do I commit when moving files in a git? (Jgit)

I am implementing a bot that performs scheduled backups.
from a front-end a user will be able to change the folder names the backups are stored in.
according to:
What's the purpose of git-mv?
mv oldname newname
git add newname
git rm oldname
is what I want to do when a folder or file name is to be changed.
so I move the files using Java FileUtils,
add the new file/folder and remove the old file/folder using:
git.add().addFilepattern(newName).call();
git.rm().addFilepattern(oldName).call();
git.commit().setAll(true).setMessage("Renamed group "+oldName+ " to " +newName).call();
The main goal being: to preserve the history of the files being moved.
Should I commit after adding the 'new' file before removing the 'old'?
Is my current order of operations fine and committing after both operations should preserve the change history?
I am still new to Git and how the logging works, in TortoiseGit it shows files added and removed, would it show up as a move in the log if the process worked?
Thank you for your time.
Git does not actually record history of individual files in the repository; it records the history of the entire repository as a single unit. There's nothing in a commit that explicitly says that the foo.txt in revision 2 is a continuation of the bar.txt in revision 1. Instead, renames are inferred by tools that examine the repository — after the changes have been committed — using the heuristic that if a commit removes a file and also creates another file with similar contents, the old file was renamed to the new one.
This heuristic only recognizes a rename if both changes occur in the same commit. If you remove a file, commit, then add the file back with a different name and commit again, Git will see that as separate deletion and addition of unrelated files.
Note that rename detection is optional and tools may not do it by default. With git log you need to use the -M option, for example, or do git config --bool diff.renames true.
I'm not familiar with JGit, but your Java code should probably mirror what Git is actually doing beneath the interface when you run your command. Since you are already doing this, I don't see any problem. I would make sure that the entire renaming operation appears in a single commit. There are several reasons for wanting to do this. You may want to revert the renaming at some point. If you have a single commit, it would be easy to do this via git revert.
With regard to preserving the history, renaming a file makes it harder to track the history, but not impossible, e.g.
git log --follow ./path/to/file

Eclipse can not commit all files to Git

I have project in eclipse. I was developing it. Everything was fine. I use git to commit changes.
But starting from some point I noticed that not all files in git repository are committed.
When I do commit, git just do not show it under list of available files. I have tried to commit each file - no result, tried "add to index" - no result.
Does somebody know what can be the reason? I have such problem first time.
And no tracking symbol ">" appears.
In order to see if there is an issue with a .gitignore, switch back to the command line, and type:
git check-ignore -v -- yourFile
You will immediately see if one of the .gitignore rules applies to it or not.

Categories