My primary development environment is within Windows but for Git, I try to mainly use the command line for doing most things and occasionally use TortoiseGit for others (such as viewing viewing logs or rebasing). Usually when switching branches, there are no problems when it's removing and restoring files. But certain programs lock these files (e.g., editing CSV files in Excel) which causes minor issues when switching branches.
If switching from the command prompt and a file is locked, it'll simply notify you that it was unable to unlink the file and ask you if you want to retry. This will give me a chance to close the program that has the lock and let it try again.
switching from command prompt
However, if I were to switch branches through TortoiseGit, it will have the error but will act as if the response was N and finish up leaving the files in their current state. It gets a little annoying as I have to go back and manually revert the files. I'd rather have it wait and ask me to try again, like it usually does with other actions.
switching from TortoiseGit
Is there any way I can force TortoiseGit to halt and ask me to retry unlinking the file when switching branches? Or is this just not a feature of TortoiseGit?
Up to TortoiseGit 2.2.3 the yes/no question wrapper (GIT_ASK_YESNO) was not implemented. Starting with 2.2.4 this will be supported, however, I don't know why after an "error" success is reported by git.exe.
Related
So, I'm working on a bash script to manage some of my version control commands that I've been doing manually via the command line. It's a long story why I'm doing this, and not just using one of the SVN tools out there. Short answer: I'm using both Git and SVN, with the same codebase, but for different purposes. These scripts allow me to execute all the commands at once.
Anyway, I've got the script going great. Everything works perfectly. My one concern is the times that SVN prompts the user for input. The big one I'm thinking about is merge conflicts. Whenever there's a conflict when its downloading files from the server, it prompts the user to take action about that conflict.
Ideally, I want to suppress all output from the SVN command during execution, and if there are merge conflicts, just postpone them and then tell the user at the end that such conflicts exist (the user can then go in and resolve them).
So, for the question: Is there a way to use bash to handle those user input prompts. To detect them, respond to them, and keep the process going?
For the sake of argument, let's work off of this simple SVN command. Assume that this command is in a Bash script, and when it is executed there is a merge conflict. What, if anything, can I do?
svn update .
Thanks in advance.
I use the
svn update my_checkout_path --accept postpone --config-option config:miscellany:preserved-conflict-file-exts=*
Where --accept postpone is to skip all auto conflict operations, and preserved-conflict-file-exts is to dissallow auto merge for all files.
Read more:
http://svnbook.red-bean.com/en/1.8/svn.tour.cycle.html#svn.tour.cycle.resolve.pending
http://svnbook.red-bean.com/en/1.8/svn.advanced.confarea.html
Update
To detect the conflict situation you can look for Summary of conflicts string in update output (if you sure you have use the english version).
Periodically, when I'm doing git p4 submit, I get a nasty error:
Could not determine file type for rails_project/public/favicon.ico
(result: '//mydepot/main/rails_project/public/favicon.ico#1 - add
default change (binary+l) *exclusive*')
In each case, it's some odd binary-type file that confuses the thing (like the favicon.ico above), or (most often) a graphic, like a PNG. And this kills the submit and leaves all the files that were opened before it in an opened state, but not yet submitted...
Resolving this ends up being a pain in the ass, where I end up having to use p4v to go in and manually submit half of what I was trying to submit via a new changelist, and then finish my submit (crossing my fingers that I don't hit another weird file and get stuck again).
(this is on git version 1.8.3.2 on a Mac with OS X Mountain Lion)
Has anyone come up with a way to make git p4 behave properly? Any ideas?
Looking at https://github.com/ermshiperete/git-p4/blob/master/git-p4 for "Could not determine file type for " the regex 're.match(".*\((.+)\)\r?$", result)' isn't matching against '//mydepot/main/rails_project/public/favicon.ico#1 - add
default change (binary+l) *exclusive*'.
I guess "*exclusive*" is new from perforce. or at least the git-p4 developer(s) haven't encountered it.
The easiest solution is probably to teach git-p4 about the new perforce syntax, and submit a patch.
EDIT:
Thinking about it - you probably don't want to use git-p4 for any files you (or your company) have decided should have exclusive locks, since git will break the exclusiveness of the locks.
I newly started working on Github via their native Windows Application, it's quite good however it's crashing so often and the horrible thing is that I lose all the recent changes after it's crashing. All the local files will rollback to the last version of the successful commit or sync.
I'm on a 64bit windows 8 machine. Any ideas?
The exact error after crash is Couldn't find a HEAD in this repository
I sent an email to GitHub For Windows support. Their answer was this:
Hi David,
I am sorry for the trouble.
I have been able to reproduce this problem, and have filed a report for our developers to look at. The reason the application is crashing is likely due to merge conflicts between the local and remote repositories.
The easiest way to resolve this would be to go into the repository that is saying 'failed looking for HEAD', closing that pop-up, and clicking Tools -> Open a Shell Here.
From the shell, you can run 'git reset --merge' to undo the merge that caused GitHub for Windows to crash.
From there, run 'git checkout master' to switch from the detached HEAD.
After that, run 'git pull' in the shell to pull down any new changes. It will prompt you to fix any merge conflicts (which is what caused the app to crash).
Once you fix the merge conflicts in the files, you should then be able to sync correctly in GitHub for WIndows.
I have been testing this issue, and after I resolved the conflicts with the initial crash, I no longer had any further trouble with GitHub for Windows. It correctly prompted me to open the shell and resolve merge conflicts rather than crashing.
Let me know if you have any further questions, and hopefully we will have a fix out for this soon.
Best,
Steve
This is the solution I received from Github support. I'll copy & paste the exact text here:
The easiest way to resolve this would be to go into the repository that is saying 'failed looking for HEAD', closing that pop-up, and clicking Tools -> Open a Shell Here. From the shell, you can run 'git reset --merge' to undo the merge that caused GitHub for Windows to crash. After that, run 'git pull' in the shell to pull down any changes. It will prompt you to fix any merge conflicts. Once you fix the merge conflicts in the files, you should then be able to sync correctly in GitHub for WIndows.
I have been testing this issue, and after I resolved the conflicts with the initial crash, I no longer had any further trouble with GitHub for Windows. It correctly prompted me to open the shell and resolve merge conflicts rather than crashing.
I had this problem after I made an unstable change to my .gitconfig user file.
I only detected the issue after I tried using TortoiseGIT and it outlined the error parsting the config file with an unexpected token.
So the fix was to correct the bad .gitconfig file.
Often when I do a checkout of a different branch, or a reset, I will get 'permission denied' errors from windows for one to a dozen files - but the particular files vary from run to run. Here's the output from a test I just did, with GIT_TRACE=1. The trace only added the one line before the error message:
$ git checkout master
trace: built-in: git 'checkout' 'master'
error: git checkout-index: unable to create file dotnet/src/myfile.cs (Permission denied)
D dotnet/src/myfile.cs
Switched to branch "master"
I'm pretty sure this is some race with a virus scanner or other indexing service on my machine. If the race persisted, I could use sysinternals to see what process has the file handle open. However, it happens very quickly, and I'm not aware of a tool that will show me this conflict. Surprisingly, I haven't found anyone describing similar behavior.
How do I make these errors stop, or diagnose the problem further?
I'm specifically looking to end the file access race by identifying whatever process is doing the simultaneous access. So suggestions for a tool that shows which process has a file locked when an edit is denied would be very helpful. I'm aware of 'unlocker' and similar tools which will show me what process holds a file locked for a period of time. This doesn't work for this issue, because the process keeps the file locked for a very short period. So the tool needs to collect the appropriate data without my intervention, as I'm too slow.
It might be the Windows Search Indexer, which tries do index files as they are created. I ran into this issue with svn checkout and had to exclude that directory from indexing before I could successfully checkout a full project.
See my post https://connect.microsoft.com/VisualStudio/feedback/details/676699/cannot-open-linker-output-for-writing-or-cannot-close-file
Not git related!
Sysinternals' process monitor reveals that Windows explorer interferes with newly created files, perhaps due to some plugin or what, but it happens.
Disabling UAC Virtualization seems to have fixed the problem.
See http://code.google.com/p/msysgit/issues/detail?id=320
You can begin with a:
GIT_TRACE=1
But it may not display much more than your original message regarding this file.
The usual cause is some opened editor which wants to reload the files when changed, and that can conflict with git's file manipulations.
That means: the usual strategy is to repeat your git command after having close as many other applications as you can.
I haven't found anyone describing similar behavior
See this thread for instance, ot this one, both on Cygwin.
What version of Git are you using (Git on Cygwin, or MSysGit, in a Cygwin session or a Dos session?)
You could try Filemon from sys internals
I've been using Subversion for code control with TortoiseSVN to interface with the server for the past few months, and in general it's been going great! However, occasionally my FoxPro IDE will change the case of a file extension without warning where "program.prg" becomes "program.PRG") TortoiseSVN apparently takes this to mean the first file was removed, becoming flagged as "missing" and the second name comes up as "non-versioned", wreaking havoc on my ability to track changes to the file. I understand that Subversion has it origins in the case-sensitive world of *nix but, is there any way to control this behavior in either Subversion or TortoiseSVN to be file name case-insensitive when used with Windows?
Unfortunately, Subversion is case-sensitive. This is due to the fact that files from Subversion can be checked out on both case-sensitive file systems (e.g., *nix) and case-insensitive file systems (e.g., Windows, Mac).
This pre-commit hook script may help you avoid problems when you check in files. If it doesn't solve your problem, my best suggestion is to write a little script to make sure that all extensions are lowercase and run it every time before you check in/check out. It'll be a PITA, but maybe your best bet.
Windows does support case sensitivity, but you must send it the correct POSIX flags on CreateFile from the Windows API! A registry key may need changed (SFU/Tools for Unix and Ultimate Windows 7 has this registry entry already set so windows supports case sensitive file names).
Windows is designed off of Unix, but things such as Explorer.exe and other programs are designed to disallow case sensitivity for backwards compatibility and security (mostly when dealing with dos executing notepad.exe vs. NOTEPAD.EXE, where all caps is a virus or malware).
But Vista+ has security attributes which makes this obsolete.
TortiousSVN just doesn't support passing this posix flag while making and renaming files.
I use TortoiseSVN with VFP, and it mostly-seamlessly handles the case flipping. The only time it doesn't is if I have the file open in the IDE when I try to do the commit: the file lock VFP holds confuses it. Is this where your problem comes in, or are there other issues?
I did a presentation at FoxForward last year about using VFP with Subversion: most of the presentation dealt with the command line, but there are a couple of slides at the end that have links to tools that help you work with Subversion in VFP. http://docs.google.com/Presentation?id=dfxkh6x4_3ghnqc4
Kit, you comment above that VFP's binary-based source files are tough to work with in Subversion. The link I gave above mentions a couple of tools to make it easier, but the one I work with is Christof Wollenhaupt's TwoFox utility -- it converts a VFP project to text-only. You have to run it manually, but I don't have a problem with that.
http://www.foxpert.com/docs/cvs.en.htm
I believe the random upper and lower case on the extensions isn't random at all.
I remember testing on this. If you modify a program from the project manager.
By clicking on the modify button let's say. And then save the changes the extension is lower case. If you do a modify command from the command window and save the changes the extension is upper case. Apparently the coders at Microsoft didn't worry about the extension case being the same.
TortoiseSVN has a Repairing File Renames feature. It requires manual intervention and it actually issues a file rename operation to be committed but nonetheless addresses current use case by keeping file history.
Nope you sure can't. SVN is case-sensitive unless you were to rewrite the code somehow ... it is open-source.
We had a similar problem and I found a better solution than the ones exposed here, so I'm sharing it now:
For commits done manualy, now TortoiseSVN fixes the case of the file names automatically: it renames the local files to match the case of the versioned files (just by opening the commit window in that path), so there should be no problem with that.
For automated commits you cannot use TortoiseSVN, as it requires you to manually confirm the commit (it opens the commit window with a specific message, but you still have to click ok). But if you directly use Subversion (svn) to make an automated commit, then you will have the case-sensitive issue on that commit, as Subversion is still case-sensitive...
How to solve this for automated commits? Well, I tried a mixed approach: creating a batch file called FixCaseSensitiveFileNames.bat that you may call passing the path you want to fix before the commit, for example: call FixCaseSensitiveFileNames.bat C:\MyRepo. The batch file opens TortoiseSVN for a manual commit, and that automatically fixes the file names, but then it closes the commit window after a predefined pause, so you can continue with the automated commit with the case-sensitive file names already fixed. The pause is emulated with a local ping, and you can change the duration by changing the -n argument, which is the number of tries. If you don't make a long enough pause, it exist the risk to close the TortoiseSVN window before it makes its magic fix. Here it is the code of the batch file:
#echo off
REM *** This BAT uses TortoiseSVN to fix the case-sensitive names of the files in Subversion
REM *** Call it before an automated commit. The Tortoise commit fixes this issue for manual commits,
REM *** so the trick is opening the commit window and close it automatically after a pause (with ping).
REM *** %1 = path to be fixed
start TortoiseProc.exe /command:commit /path:"%1"
ping localhost -n 10 >nul
taskkill /im TortoiseProc.exe
This totally solved the issue for our automated daily build process. The only problem I see is a window will open for a few seconds, which was not a problem for our daily build, but if that is a problem for you there could be workarounds too...