I've been playing around with git at home and I really like the idea of local commits. Being able to commit smaller changes without spreading my potentially broken code to everyone is nice, as well as being able to revert smaller changes because of the more frequent commits.
I've been reading about the git-svn command, but I'm not sure I entirely understand how it works. We work on Visual Studio 2008 projects, and run VisualSVN which handles file renames, moves, and all that for us from within the IDE.
What I want to know is: Is it possible for me to commit to a local git repository but also commit to the remote SVN repository as well? I'd like to keep VisualSVN change tracking and committing from within the IDE, but also be able to use git to temporarily store changes. Are they likely to get in each other's way?
It works beautifully. go for it. Just don't check your .git folder into svn.
edit: erm, when I do it though, I don't bother with git-svn. I just treat the local working directory for svn as any other directory, and I tend not to care much about the previous SVN history.
I've used git-svn to keep "updating" from the remote repository, but haven't used it to commit to an svn repository, so I can't help you about that part.
What you do is simple, with all settings on default:
>git svn init <url......>
>git svn fetch
When you do that, it fetches it to a "remote" branch called "git-svn".
To merge it with your current branch:
>git merge git-svn
You may run into some issues if you're using git-svn after the fact. What I mean by that is: you already have checkout the project using svn, then you also created a git repository in your local working svn directory. Then you use git-svn on top of that.
Two issues I had to deal with:
Line endings. svn might convert line endings to windows, while git-svn will preserve them to unix style. So you might get tons of conflicts due to the line ending differences.
So to be sure, use a tool to convert line endings on all files to unix (or windows, depending on what line ending is used in the svn repo).
svn keyword expansion. e.g. $Id$
git-svn will not expand these keywords, while svn will. So you'll have conflicts there as well. Again, use a tool (or write a script) that converts all instances of $Id .......crap.....$ to just $Id$`
Related
I'm working in a large corporate enterprise where all the developer machines are Windows 7 Enterprise SP1.
I'm running major migration project from RTC to git (resulting in something like 1200 git repos). There are no Windows servers in the production environment, build or test environments - everything is either Solaris or RedHat. The solution will be rolled out to ~200 developers.
There is generally a push to use more Unix-command line tools and there are a few different alternatives on Windows such as: Cygwin, git-bash, cmder. I have avoided running a full linux VM because that introduces too many other problems (most developers don't have local admin rights and the internet proxy is a constant hassle so I don't want to make networking a bigger problem with NAT).
I've been running Cygwin (mintty 2.6.2) for the past 8 months and it's been ok until today where I hit a very concerning issue with git (v2.8.3) where git status reported a clean working directory even though multiple files and folders had been deleted in the repo. Only after I recreated a folder with the same name as one of the deleted folders did all the deleted files appear correctly with git status.
I'll explain the symptoms and what I was doing but so far I have not reproduced the issue. My suspicion is that the problem lays somewhere between the emulated linux file system and the actual windows file system. Is there any difference in the way the various emulators achieve this?
The specific problem I hit had these symptoms:
Client side:
git status showed a clean working directory
git log showed 3 commits A, B and C (commit C checked out)
The repo contents was one folder containing a file, 2 more files in the root folder, plus the .git folder with contents
git stash list was empty
git branch -a reports only master, HEAD and origin/master
Server side:
The origin contained 13 additional folders, each with one file
The origin also contained commits A, B and C
Only master branch is present
Commit A was the initial empty commit.
Commit B was where all contents was added, 14 folders and 16 files.
Commit C was another empty commit
Commit A and Commit C were both created using tools to assist with the migration. It runs two commands: "git init" and "git commit --allow-empty -m 'initial commmit'"
I could not understand how git status did not report the deleted files (I remember deleting them, but it was some days previously with multiple computer hibernates, and probably a restart or two from resuming my work)
Trying to figure out what had happened I did this:
I created a new file then ran "git add", "git commit" (creating D) and "git push."
Commit D appeared on the server with the new file. The 13 additional folders and files were still present on the server.
I ran "git pull" which returned "already up to date"
I checked the changes for every commit on the client side and on the server side and every diff was the same
I cloned a new copy of the repo and the contents matched the server with the 13 additional files and folders with the additional commit D and extra file
I then recreated a folder with the same name as one of the deleted folders and ran "git status" where finally all of the deleted files and folders were reported correctly.
I cannot explain this any other way except for a serious bug which simply makes it unsafe to use git in Cygwin. I hope the community may have some advice for me in this area and that this is phrased as a clear enough question that the mods don't flag my post.
I will do my best to try and reproduce the problem and update the issue with more info when I have some.
Edit: Update 2016-12-08
My attempts to reproduce the error have been unsuccessful. If I see it again during my work I will update this issue.
I've never seen such behaviour with Git on Cygwin. Actually currently I use Git for Windows from within Cygwin and it also works fine. I used to use the Cygwin Git, but I had the feeling that it is slower than Git for Windows, such I switched to Git for Windows used from within Cygwin and it works great.
If you at some point update the Windows boxes to Windows 10, you can also consider another option, the Windows Subsytem for Linux which is an Ubuntu based virutal Linux environment developed by MS together with Canonical. It is still in the process of getting mature and not fully usable yet in my opinion, but there you then have a natively supported virutal Linux environment where you can use apt-get and so on.
Issue you mentioned are really unexpected, and I doubt Cygwin can cause it. But you have following options
git comes with git bash, which support all major unix commands and it looks completely like unix shell. I am using git version 2.9 on windows 10 and heavily use major unix command like grep, sed & find , and they all work excellent. Even it support vi but I don't use it
git comes with git CMD, and same git commands will work on windows command prompt as they do on unix. You shouldn't need a separate emulator with this.
Though you mention you are using Windows 7, but now Windows 10 comes with native support for Unix Bash
You can use gnuwin32 but I doubt it will be better than Cygwin
First of all, I am new to Git. Using Git Bash, I created a feature branch 123-Feature-A using git branch 123-Feature-A, checked it out and then added some files through Visual Studio 2010. Git status showed the new files, I added them using git add . - since I have the VS2010 Git Source Control provider installed, I can see the icon changed to indicate that the file has been added.
When I want to switch branches I run something like git commit -a -m "added files" in the feature branch and then switch back to the master branch. When I am in the master branch, I see the files in VS2010, but the icon has a exclamation point and when I try to open it, VS tells me it does not exist - is there a setting in VS to hide files that I added in Brand-A, if I switch to Branch-B
It's been a while, but I think when I had this same issue I installed a git extension to VS.
Try http://www.codeproject.com/Articles/354101/Source-Code-Versioning-with-Git-in-Visual-Studio Or: http://gitscc.codeplex.com/
If you install one of these, make sure to use it consistently to manage git. That will keep VS up to date.
your workflow is totally fine from Git stand point but may be confusing for VS, assuming you have no Git support in it. Eclipse with git plugin detects this scenario just fine and if needed F5 (project refresh) resolves most of issues.
Just double check that you do have git support in your VS, i.e. that you can for example make git commits, switch branches etc. Otherwise, VS will be always confused in such scenarios, because of the way how git operates when branch is changed.
As part of our code repository, we have a symlink which is internal to the working tree.
Zend -> ZendFramework1.10/library/Zend
This works fine for all the developers running Linux or OS X, but we're now getting some people trying to use the repository on Windows.
The functionality of the symlink can be replicated by deleting the link git creates, and using mklink to create the equivalent directory junction.
However, git now sees this as the deletion of the symbolic link, and the addition of a proper directory.
I'm looking for a way to have the two co-exist, is there a way to tell the Windows machines to ignore the Zend directory, even though it's technically versioned. If this breaks when the files in that directory change then so be it, but it'd be nice to be able to work with the rest of the repo without having to worry about the link.
You can use git-update-index to tell git to ignore changes to the file:
git update-index --assume-unchanged Zend
You could probably use cygwin on the machines running windows.
As Magnus Skog has suggested, git under cygwin copes correctly with the symlinks. I switched away from Git for Windows for this reason alone. However you need to weigh up this advantage against the overhead of setting up the cygwin environment for your Windows users (particularly for those unfamiliar with *nix and the command line; for example there are a number of outstanding issues when trying to use Cygwin and TortoiseGit.)
I have a problem with git.
Basically, here is what I have. I access a svn repository through git. Until now, on python files, everything worked fine.
But lately I also added some pyd, dll and lib files on the repository. THe first update went well. But then, these files have been modified and since then I can't update. These files were added from a windows computer with TortoiseSvn on the svn repository.
If I do a git svn rebase on linux, everything works fine.
If I do a git svn rebase on windows with msysgit (and also tortoisegit), I have the following error : fatal: write error: Invalid argument
If I do a git svn rebase on windows with cygwin, I have the following error : didn't find newline after blob at /usr/lib/perl5/vendor_perl/5.10/Git.pm line 916
I tried several stuff (autocrlf true/false, safecrlf true/false), adding .gitattributes file with the following line *.* -crlf -diff -merge and nothing worked.
I'm a little stuck here so any suggestion would be welcome.
Thanks in advance.
Had identical issue with Msysgit v1.7.2.3, the latest version as at 29 Sep 10, and wanted to share my findings here (Google turns up several cases, but no solutions).
Trying to do "git svn rebase" on a repo (that has this has worked on plenty of times in the past) consistently failed with a "fatal: write error: Invalid argument" after a certain number of commits. The sync would then revert to the beginning again.
I believe this is a bug in Msysgit relating to large(ish) binaries and available memory (on a Win XP SP3 system with 4GB RAM and plenty free HD space). The remote system was the DotNetNuke SVN repo on CodePlex (https://dotnetnuke.svn.codeplex.com/svn).
Initially it was choking on a 330KB "CHM" file (~212th commit, r52261). It consistently did so, even after disabling Avast AV, Google Desktop, etc and verifying that there were no other processes with locks on the repo folder. After a reboot (but opening Outlook, Dreamweaver, etc), it then was consistently and repeatedly failing on a ~15.3MB DLL (~416th commit, same revision).
Finally, after another reboot, disabling Avast, Carbonite and Google Desktop and running no other programs, the sync worked first time.
This seems to point firmly to my conclusion that it was an available memory issue, probably linked to the presence of a largish binary and large number of commits in the revision. Note that I also tried "git fsck", "git svn reset xx" and tweaking the "packSizeLimit" / "usedeltabaseoffset" config vars, without success.
I've found that the best policy for using Git on windows is to tell it to not do anything about line endings.
I don't know if that will help you recover your current git repo, but it's worth a shot.
I set:
[core]
autocrlf = false
I like TortoiseSVN's Windows integration. Is there something like that for dealing with git-svn? I'd even go with a less integrated GUI if it is quick enough to access. What I don't want is a CLI as I rarely would have a command prompt sitting in the correct directory.
This is a related question but for Linux
TortoiseGit (https://tortoisegit.org/) added basic support for git-svn in release 0.8.1.0:
The release log says:
Add Basic Git-SVN Operation:
Add SVN DCommit Command
Add "SVN Rebase" and "SVN DCommit"
command at shell contextmenu
Support Git svn-clone at clone
dialog.
Have a look at TortoiseGit which is a TortoiseSVN clone for Git.
The easiest way I found was to use the git gui, and add a git svn dcommit and git svn rebase command to the Tools menu.
If you install msysGit, it will even put a 'Git GUI here' command in your context menu.
This has the advantage of not requiring any additional software apart from git itself, and will work on every platform that git (gui) runs on.
Edit: I should mention that this is exactly the way I have been productively using git against our svn-repos for a few months now. Works just fine. And it's the same on Windows, Linux, whatever. So no need to use different tools for the same job, depending on the OS.
Try SmartGit , it has almost all the functions console has and it has great GUI. http://www.syntevo.com/index.html
A sideways and very late answer, but maybe useful to later spectators, re why you don't want a CLI; assuming you're using XP install the Microsoft Command Prompt Here Powertoy which gives you an Explorer right-click shortcut on a folder. I use it all the time.
Windows 7 has the feature out of the box, but you have to hold down some key while you right click, I think.. shift or alt or something.
Also, Tortoisegit now apparently has git-svn features, I am going to check them out..
The best GUI tool for for using git local and svn as a server is SmartGitHg from syntevo (works for Windows, Lunux and OS X). For OS X you cal also use SourceTree from Atlassian. Windows Version of SourceTree doesn't support SVN.
You can use TortoiseSVN itself. That's what I do.
One may use any Git client while using the server-side Git-SVN synchronization setup. Have a look at SubGit to achieve that.
One has to install SubGit into Subversion repository:
$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify your branches and tags
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL
SubGit converts Subversion repository into Git (it works in opposite direction as well) and installs SVN and Git hooks. These hooks are triggered by svn commit and git push as result all incoming modifications are instantly replicated to Git or SVN correspondingly. For more details please refer to SubGit documentation and git-svn comparison.
Starting from version 2.0 (not yet released at the moment of posting) SubGit allows to synchronized Subversion and Git repositories located on different hosts.
SubGit is a commercial tool. It is free for open-source, academic and small projects (up to 10 committers).
Full disclosure: I'm one of SubGit developers.
I have not seen best tool in past related to SVN like gui, but Git has now made something very useful and easy try Git Desktop for windows:
https://desktop.github.com/