I use GIT and what I constantly see is that git shows that entire SomeModel.jpr contents were removed and replaced with the same contents. File stays the same. Well sometimes something changes and you miss it in whole soup.
Build JDEVADF_11.1.2.3.0_GENERIC_120914.0223.6276.1
This is probably a problem with your git configuration. I saw this to when I worked on a Windows system and git is configured to use only line feed as line terminator. Check your git settings and play with the line terminator settings (auto or leave as is).
Related
I am trying to figure out how to correctly rename files with git while using Xcode.
I made a test project, with a few commits, then renamed a file in Xcode, verified that the git status did say it was being renamed, and then committed outside of Xcode. This was in accordance with this answer to a SO question (Handling file renames in git).
I go back in to Xcode, try to look into the history of that file before the name change (in the version editor assistant window), and I get the error "This file does not exist in the index." While that is true, the file did not exist at that point, its predecessor did. When I go to the terminal, and run git log --follow myFile.m, I do see all commits, even those before the rename. So with that, the history is there, but Xcode doesn't seem to know how to find it.
How can you follow before a rename of a file in git version control when using Xcode?
PS. It does seem that the blame functionality can see before the name change, but the version editor can not.
I had the same error today and as suggested by matt
the best solution is to use an alternate Git GUI.
I finally solved this by installing the great GitX app by rowanj.
Then i saw the uncommitted change and simply commit it.
TY Xcode for being too git-simple and renaming-painful !
when I'm trying to commit my code project it shows a file called 'UserInterfaceState.xcuserstate' which has to be committed. once i commit it and try to push my project to git ,the Xcode gives me a popup message saying that 'The working copy "app" has uncommitted changes.' and when I try to commit again I get the same file 'UserInterfaceState.xcuserstate' to be committed again. Can anybody help me with this?
UserInterfaceState.xcuserstate is where Xcode saves your GUI states, such as window positions, open tabs, expanded nodes in the project inspector etc.
Simply resizing the Xcode window will cause this file to change and be flagged as modified by your source control system. You can make your SCM system ignore specific files that are not important to the project itself.
You want Git to ignore the file, you can add it to the .gitignore file, but you have to remove the tracking. To stop tracking a file that is currently tracked, use git rm –cached.
git rm --cached ProjectFolder.xcodeproj/project.xcworkspace/xcuserdata/myUserName.xcuserdatad/UserInterfaceState.xcuserstate
git commit -m "Removed file that shouldn't be tracked"
Afterwards the .gitignore will take effect of UserInterfaceState.xcuserstate
Now onwards you wont get a popup message saying that 'The working copy "app" has uncommitted changes.'
I need to add a SQL file to my Git repository. For some reason Tower or Git on the command line does not see that I've added a new file whenever it ends in .sql.
I've tried creating an empty .sql and removed everything in .gitignore, but it still doesn't see it.
Any ideas?
You probably have a global gitignore set up. This page on GitHub https://help.github.com/articles/ignoring-files recommends that SQL files are included in a global git ignore.
Follow instruction on that page to set your own global rules.
Is there a way that I can review the changes made to a file?
Basically, someone has logged onto my server and made unauthorized changes to a file, this has taken down a whole site. I want to see what the file read before the changes were made. The server is a standard install of centos and apache.
Unfortunately, this file lives outside of the svn (it's a config file).
If the person used copy and cut in vim, and didn‘t clean the registers afterwards, you might find remnants of the changes with :reg in vim.
Which might at least make it easier to identify some parts of the file that were changed.
In vim7.3 there is a setting that allows you to undo changes between sessions. You have to have in your .vimrc the following
set undofile
if you vim did not have this setting there is no hope to recover what the original state of the file before editing it with vim.
If it was set then you can just type u in vim to undo the changes there were made.
The is a vim plugin, gundo, that allows you to have a nice visualization
of the past state of the file (again, you would have to have the option set, and the file were the changes are kept would have to exist).
I was wondering if I right click on a file in the SVN repo browser, does it get permanently deleted? can it be recovered?
This question/answer from the SVN FAQ might interest you :
How do I completely remove a file from the repository's history?
There are special cases where you
might want to destroy all evidence of
a file or commit. (Perhaps somebody
accidentally committed a confidential
document.) This isn't so easy, because
Subversion is deliberately designed to
never lose information. Revisions are
immutable trees which build upon one
another. Removing a revision from
history would cause a domino effect,
creating chaos in all subsequent
revisions and possibly invalidating
all working copies.
The project has plans, however, to
someday implement an svnadmin obliterate command which would
accomplish the task of permanently
deleting information. (See issue 516.)
In the meantime, your only recourse is
to svnadmin dump your repository, then
pipe the dumpfile through
svndumpfilter (excluding the bad path)
into an svnadmin load command.
If it's that hard, there are little chances it can be done easily from Tortoise SVN...
(And it's not the goal of Source Control...)
You'll find that you can only delete from the Repo Browser when you are viewing the HEAD revision. This is identical to deleting a file from your working copy and then checking in the delete. In both cases, you'll be able to restore from the previous revision.
Deleting a file via the repo-browser context menu basically creates a new global revision where just that file was deleted, so it appears in the log as such - you can always revert to that revision to get the file back, or you can just pull it directly from the repository into your working copy.
No... Deleting a file (even using the repo browser) only affects working copies. It would be a pretty lousy revision control system if you couldn't recover a file from the past. It is actually pretty difficult to modify files in a committed revision, even if you have root access to the server.
Doesn't right-click just bring up some sort of menu? And with SVN is that you can always revert anyways.
I deleted a top level directory from Repo Browser by accident and the only way to get it back was the following:
Export the top level folder from a previous version history
Make a new folder in the repository to replace the one deleted.
Add the exported files back to the new directory (same name as previous)
Update the working copy, it will delete and then re-add the same files.
Its annoying but at least the working and repo will be back in sync. The "Revert Changes from this Revision" didnt work for undoing repo deletes, it only reverts in working directory not the "Undo" the delete to the repository.