I have a directory of shortcuts that I've committed to a git repo. It appears that Windows modifies the shortcut file contents but retains what the shortcut points to.
So git shows these shortcut files as different but just reports them as binary differences so there is no way to know what really changed.
I ended up writing a cygwin shell script git diff-shortcuts to properly show if a shortcut file has changed but it's so clunky I'd like to see how others deal with this situation (if they do). For the shortcuts that haven't really changed, I run git checkout -- MyToolbar\shortcut-22.lnk
The reason for the shortcuts is simple. I have a set of scripts that I've committed to a git repo and clone them onto a local windows host when I do development. For example, c:\loc\myenv. I then add the shortcuts to my Windows taskbar, by right clicking and adding a "new toolbar..." and point to c:\loc\myenv\MyToolbar which has all of my desired shortcuts.
I think think this question will largely be ignored but wanted to have it here in case others might find it useful.
See also How does git handle Windows NTFS junction points?
I expect to answer this question if no one else provides an answer.
Related
Using Git on Windows, I'm trying to deal with content that's external to my git repo. We have artwork and content files for instance that are being updated by non git-users in google drive so to capture these changes I've setup something similar to the following;
d:\MyRepo
\.git
\code1
\images1
\fonts (junction) => c:\users\%username%\google drive\designerLtd\fonts
\etc
Where 'fonts' is a folder has been linked using either junction.exe or mklink /j (same thing). This generally works out great because Git status immediately highlights new changes (either on purpose or by accident) and prepares them for checkin or undo.
ISSUE: sometimes when switching branches Git prunes the linked directories and re-creates them if content in those folders is different between branches. In effect it breaks the link. Now Git is always correct and the build is consistent but it's not always obvious that it is no longer keeping track of those external resources.
Worse still, it can delete files in the external location. They can be recovered from git of course, but it's very unwieldy.
Swapping the content in the external locations when branches are switched isn't a problem, because there's only one PC that's hooked up this way and they're easily merged, but I just wish it didn't break the links.
QUESTION: Is there a better way to allow external junction points within a Git repo on Windows?
To be clear, there are no symlinks in the GIT repository (yet) as far as I know and this isn't a question about interoperability between Unix and Windows git clients (which most of the other questions on SO seem to relate to).
You can modify permissions of the junction point so that git can no longer delete it. Git usually doesn't care if removing a directory fails (except if it needs to replace the directory with a file).
See "Usage Recommendations" in https://support.microsoft.com/en-us/kb/205524
I am using Git Shell (the module for PowerShell) on Windows. It's the one that got installed when I installed Git for Windows. When I run a command that results in a lot of text such as git log I get a page of results and then a ":" at the bottom of the screen. I guess it's a continuation prompt because I press ENTER and get another screen of data. I can't usually recover to a normal prompt after this happens though. I get the text (END) at the bottom of the shell and it looks like it's masking the first few characters of whatever command I try to type and it even seems to act a little sporadic. I can't seem to figure it out. Any ideas?
Several of the git commands use a pager to allow you to view one screen full of information at a time. The one that come with git is usually less (more info). You can visit the link for common commands, but as you've found the most important is q to quit to get back to the command prompt. The next most useful one I've found is space to move to the next screen full.
You can change the pager used if you like in the git config file's core.pager field.
Just to add to the existing answers, the normal "windows" pager is more.com, which is usually referenced from cmd as simply more, but hidden by the function more with similar functionality in PowerShell. If you set
git config --global core.pager more.com
your problems should go away (although at the cost of features that exist in less but not more).
This is an old question, but I thought I would mention that git also provides a --no-pager option for you to leverage as well.
git --no-pager log
Hope that helps someone.
I have been using git on my windows box to track a project I am working on alone. I had to copy the files to a linux box. I made substantial edits to the source on the linux box to get it working w/some components also on the linux box. How can I "properly" push the newly edited source on the linux box to the tree on github now?
I tried copying the root of the project on the linux box to my windows machine and did a "git add *" on the windows box at the root, but "git status" makes it look like all the files would be seen as "new", which I do not want. How can I do this without git thinking they're all new files, and instead modified files, as if I had performed all the edits on the windows machine as in the past.
I would accept any answer that gets it done this one time (script, series of git commands, etc).
Also, is the correct way to do this in the future to checkout first on the remote box and then perform edits?
Note: I haven't committed anything to the tree yet. Just the aforementioned copy to the windows machine and then a "git add *" on the windows machine.
If I understood right, you have the same git repo on both machines, but they're independend. If it is so, you can use patch to share changes, see here http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git
Another way might be, if there is a network connection between the machines, and access to the "other" git repository might be possible, you can just pull those changes. See http://book.git-scm.com/3_distributed_workflows.html
If none applies, please provide more information, why this won't work.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Git GUI.. stage everything
My employer is finally looking into setting up some source control after much pleading by all of the developers. Unfortunately, none of our developers, inclusive of myself, have ever done much with source control. I've looked into SVN and thought that would be fine but another of the developers didn't like it. I've moved on to looking at GIT as an option. I've downloaded the GIT GUI from http://git-scm.com and started tinkering with it which brings me to my question/problem.
The web application we're trying to add to source control (GIT) is 7,386 files and 712 folders. When doing the initial commit, from what I understand, I've got to click on each file I want to commit to move it from the Unstaged Changes to Staged Changes pane. Well obviously I am hesitant to sit and click 7,386 times (once for each file to commit). Is there another faster way to do this?
I'm currently using this page as my reference to learn to use the GIT GUI http://nathanj.github.com/gitguide/tour.html. If anyone has a better tutorial/reference for using the GIT GUI I'd much appreciate linking me to it.
Thanks
To add every file (that is not ignored), use
cd /path/to/workspaceRoot
git add .
I don't use any gui, but I think this should be possible by adding a directory (the root directory in this case).
Remember to create a appropriate .gitignore file before, so no unwanted files get added. You can check, what is (un)staged with
git status
Also, there should be a context option (or something like that) in your gui, that provides status.
Extra: Additional git resource (quite good imo) http://progit.org/
From Git-GUI select all files in the "Unstaged changes" list and select "Commit->Stage to commit" in the menu.
If you're not afraid of the command line, try this tutorial instead. It's a detailed walkthrough of beginning git in 10 parts and ends with a Git reference card to help you go further. The free Pro Git book is also much applauded.
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...