Git Extensions has repeatedly added four javascript files to my commit. I have never knowingly edited these files and the diff for these files is blank. So I don't know what, if anything, is being changed.
If I select the reset option for the files, they are removed from the commit list for a while. They eventually come back, but I have yet to notice a pattern or a particular action that triggers their return.
What is likely to be causing this and what can I do to fix it?
The files are:
knockout-2.1.0.debug.js
knockout-2.1.0.js
jquery.unobtrusive-ajax.min.js
jquery.validate.unobtrusive.min.js
This was a line ending issue. There was a difference in the settings for how to handle line endings between myself and my coworkers. Correcting this difference fixed the problem.
The command git diff --ignore-space-at-eol can be used to check for any differences that are not caused by end of line spaces.
Credit goes to #SamHolder for pointing me in the right direction and providing the above command.
Related
I have read so much about the config setting core.autocrlf and what you can set it to. Yet I am having a lot of problem understanding why it doesn't work the way I expected it to.
Machine I'm working on: Windows
Experience with git: Beginner
Terminal: git bash
core.autocrlf: true
So let's begin with the first bit of confusion. I used the command echo hello > file1.txt in my working directory, then I also created a text file by opening notepad and saving it in the same location as my "file1.txt" and giving it the name "file_windows.txt". When opening both files on notepad, I saw a difference, "file1.txt" had "Unix (LF)" marked at the bottom of the notepad tab, whereas "file_windows.txt" had "Windows (CRLF)". I imagine the distinction was made since the first file was made with a unix/linux command in comparison to the other file which was created through the use of notepad and windows.
Now the problem arises when I tried adding those files to the staging area. When using the command git add file1.txt, I was faced with the following message:
warning: LF will be replaced by CRLF in file1.txt.
The file will have its original line endings in your working directory
I was a bit shocked since I thought that having core.autocrlf set to true would mean that git would make changes to the file by making sure "crlf" was replaced with "lf" when adding to the staging area, not the other way round suggested by the warning, of course the point of having that setting on was so that if let's say for example, someone on a linux platform with core.autocrlf set to false, would be able use that git repository without having to worry about some file having "crlf" instead of "lf".
Then when using the command git add file_windows.txt there would be no warnings as expected, since I imagine it is doing what it is supposed to do and replace "crlf" with "lf" when adding it to the staging area. What I am trying to get at here is that if there was for some reason to be a file that I'm working with that is in "lf", I wouldn't want it then switching it to "crlf" when I am adding it to the staging area, since there really wouldn't be a need to do so and it would probably not be beneficial.
Another thing to mention is that (although shouldn't be taken too seriously since I am a beginner using git so I don't know if it is because I am doing something wrong) when I commit both files, then use the command git checkout <commit hash> and then go open the files by start file1.txt (which opens them up on a notepad), I don't end up seeing the change which the warning stated it would make, it still shows as "Unix (LF)" and not "crlf" so it leaves me even the more confused.
Coudl someone explain what is going on please?
The warning "LF will be replaced by CRLF in file1.txt" means that it will be replaced by CRLF when you check the file out next. The file is indeed stored with LF endings in the repository, since all files subject to text handling are stored that way.
However, when you use git checkout, Git doesn't check out files which are up to date in the index. That's why you don't see git checkout modifying the files in the working tree.
This message is ultimately harmless, but it just warns you that you've placed a file into the working tree that does not use the line endings that you've requested, explicitly or implicitly, which means you may end up with different behavior next time you clone or checkout the repository. If all your tools handle any line ending gracefully, or you've properly configured your .gitattributes file to specify appropriate line endings, then you shouldn't have anything to worry about.
I have set vim as the svn editor.
Now, whenever I do 'svn ci', it opens up vim editor allowing me to enter the commit comments.
Below the comment section, there are set files which will be checked in. So, If I don't want certain files to be committed, I remove it from the list of files in the vim editor. But when I save and quit the vim editor, svn still checks-in the file I have removed in the editor.
Is this expected behavior? Or I need to set something in the svn configuration to make it work?
That list of files in the comments section is... well... just comments. It doesn't really do anything - it's just there to help you by letting you see what you are committing.
If you want to not commit certain files, you have to do it beforehand:
You can specify the files you want commit in the svn commit command instead of committing everything.
You can add the ignored files to your svn:ignore property.
You can use some GUI tool that'll let you visually select what to commit and what not.
There is some trick with changelists. Haven't tested it(I don't use SVN since it's crap), just found it in this answer when I googled.
Use Git with git-svn, and simply git reset HEAD the files you don't want to commit to unstage them.
The list in the editor is just informative; it tells you what will be committed but does not influence what will actually be committed (the relationship is the other way round). If that's not what you wanted, you have to kill the svn ci (typically by doing Ctrl+Z and then issuing the kill at the command line). To change what is committed, you need to list the files explicitly to svn ci; it only defaults to all known, modified files (i.e., those listed when you run svn status).
If the above way of working isn't to your taste, you might be better off getting one of the many GUIs that wrap around SVN. They almost universally make interactively selecting what to commit easier.
I'm a very fresh user of Perfoce, so please be patient!
I am trying to create a commit (I understand it that in Perforce it is called a changelist) of the files which have been changed. It sort of happens automatically in other VC systems, but there seems to be no easy way of doing it in p4... The problem is (maybe) that I'm not editing the files by hand, the files are generated (please don't ask me why do I have to check in the generated files...) so the whole directory tree is getting removed and then copied over with the new files. But Perforce acts as if nothing happened. In both my workspace and the depot it displays the updated files, but when someone will check them out on another machine, the files will be of the previous version.
I'm fine with doing it either through GUI or through the command line. I'd prefer the command line, because that would spare me the trouble in the long run, but it doesn't seem like it should be much hassle either way.
In other words, let's say, this is the workflow I'm used to from SVN or Git:
Run status to see what changed.
Stage / add to commit what you want to be in the next revision.
Commit and send it to the versioning server.
What I'm not able to do is the "stage" phase - because the changes are not discovered automatically.
EDIT
Ah, I think, I figured it out: reconciliation was what I needed... well, I guess if you don't marry, this word would hardly ever happen in your vocabulary :)
It appears that the proper command is reconcile. Also, as Bryan Pendleton suggested there should be status, but I must have an older version of Perforces, which doesn't have this command. This command is also available from context menu in either depot or workspace panels of Perforce graphical interface, when you click on the modified file.
I've checked out a copy of the SVN branch (my branch) locally to which I've merged from a different branch (which has a completely different folder structure). So basically there are a lot of deletions (of old files) and additions (of new files).
When I try to commit the merge to the repository (to my branch), Tortoise says
This commit is not recursive, and there are moved/renamed folders selected for commit. Such moves/renames are always performed recursively in the repository. Do you want to commit anyway?
Is it fine to proceed with this commit? If not, what should I do so that there's no problem?
Also, for some files that I've added, I've made changes after adding (if this affects the nature).
Found by Google how to fix it: press F5 in the commit window (not in the "warning popup")
See http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2831045 for details.
On 26.08.2011 22:39, Ryan J Ollos wrote:
For several months now I've been seeing the following dialog box appear when
initiating Commit. It frequently happens when attempting to commit following
a merge.
The thing I have noticed lately however is that if I Cancel and then
manually refresh the file list (F5), I don't see the message again when
initiating the commit a second time. The commit seems to succeed fine and
with no further problems.
The commit dialog monitors the working copy in a background thread for
change notifications. Such notifications are sent by the OS in case
files are modified/moved/renamed/...
If such a notification is received, the commit dialog first does a few
checks so it can drop most of them. If the notification indicates that a
file that is not checked and not visible in the commit dialog has
somehow changed, it switches back to non-recursive committing.
That's because if you have e.g. a file open in another editor and save
your changes while the commit dialog is open, then that file would get
committed as well even though you haven't checked it in the commit
dialog (it doesn't show up until you refresh the dialog with F5).
So if you see that warning dialog often, please check if there's another
tool/app running which modifies files in your working copy.
And as you noticed: if you hit F5, that 'non-recursive flag' is reset
because after a refresh, you see all the files again - even the ones you
modified after you started the dialog.
Stefan
I had the same issue but resolved it by reverting changes to files that I had marked to 'ignore-on-commit'
Once I reverted these files, then tortoisesvn was able to commit all the other files from the merge
Is it fine if i proceed with this commit?
No, your commit will ignore all changes in WC-tree and reflect only root-level changes (broken merge).
You made an error when checking out non-recursive initially. You can try to perform good, full commit using --depth infinity parameter in the CLI or find this switch in TortoiseSVN GUI.
svn commit --depth infinity . -m "Merge"
Also for some files that I've SVN-added , I've made changes after adding (If this affects the nature).
In my case that was exactly what caused the message to appear, even I unselected those files for the commit.
Ugly solution which only works safely if just a few files are affected:
Create a copy of the changed files
Revert the changed files
Commit the merge/reintegration
Copy the changed files back to the original place
Reminder to self: only reintegrate a branch if the target (trunk) is clean.
I just had the same issue. Instead of selecting all the files, I clicked on versioned and everything worked well. In my case, the option versioned selected all the files, so everything is ok now.
It looks like TortoiseSVN performs some kind of validity checking before calling commit. Good but the error message is very unclear.
When I faced this issue, I went back to using the svn command line to commit. Commit failed due to the reason that one of the folders was not up to date. After updating just that folder, I ran "svn commit" once again and it went through.
Edit: PS: Before you use try this out, make sure you do not have any files marked as "ignore on commit". "Ignore on commit" is tortoise specific and SVN commit picks these changes as well.
Just thought I'd post this because it worked for me...
The reason this happened is because I'd partially renamed one of the new projects I'd created and for some reason they all showed up as "Missing" on the commit screen.
After I removed the project and folder (which SVN had put a tick on) and put it back in as a new project again, suddenly all of the "Missing" had turned into "Added" and the commit ran fine without warning me of anything.
Hope this helps!
I saw this issue and the cause was a few added files not having the added status for no apparent reason. They were 'normal' even though the parent folder correctly showed as 'added'. I reverted those 'normal' changes and then manually re-did them. This made each added item show up twice in the commit list but it resolved the error and everything appears to be in working order now.
It didn't have anything to do with ignore-on-commit as in another answer, it just seemed like a bug in TortoiseSVN.
The problem could be, that your mergeinfo is deleted by someone or automatically, because the infos moved up in the tree. If you are gonna merge them in again, it will work for the moment. But all others will get problems with their not merged branches. SVN will loose some code and merge already submitted code again.
So reverting those files and changing them again could work, but you should not just commit the changes.
i don't know a option for tortoisesvn but u could use the command line
svn commit --non-recursive [folder]
thats sould work just as u like it to work
greeings
I changed a file locally and then I updated the repository and someone else had updated the file. However Instead of a conflict coming up and me having to go in and diff the file and select which portions from which file to use it looks like tortoise svn just merged the file instead...
That just means everything went well.
You get a conflict only when your versioning tool (svn) can't merge the two versions of a file properly.
Without knowing the details I can only guess, but if your changes wasn't in conflict with the other persons changes, then Subversion will happily merge without producing a conflict.
As a test, try adding a file with 10 numbered lines, branch it, then in one branch change the first line and in the other branch change the last line, then attempt the merge and you should observe the same happening again.
If the changes are overlapping or close to each other, you'll get merge conflicts.