I have recently decided to take the git plunge, and am really enjoying using git, even on Windows.
My current open source project lives on subversion, all devs are familiar with subversion so I would like to keep subversion as the "source of truth" for now.
Nonetheless, I want to use git, so I went ahead and created a copy of the source on github using git svn. All my work is done against the source in github and I push my changes to github. Once every few days I also push my changes to svn and rebase.
The initial import seemed to go ok, but now every time I do a "git svn rebase" I keep on getting conflicts, even on files I have not changed in my get repository. This is causing me much pain.
Eg.
$ git svn rebase
First, rewinding head to replay your work on top of it...
Applying: Added git ignore file
c:/Users/sam/Desktop/MediaBrowserGit/trunk/.git/rebase-apply/patch:12: trailing
whitespace.
*/obj/*
error: .gitignore: already exists in index
Using index info to reconstruct a base tree...
:12: trailing whitespace.
*/obj/*
warning: 1 line adds whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
Failed to merge in the changes.
Patch failed at 0001 Added git ignore file
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
rebase refs/remotes/git-svn: command returned error: 1
My questions:
Is there any way I can tell git to sync itself up with svn using svn as the source, so I can start with a clean slate. (export latest, check in changes and reset the svn refs somewhere)
Are there any tips and tricks to getting this scenario to work consistently?
Should I have the core.safecrlf and core.autocrlf options set to true? It seems I will need a bit of hoop jumping.
Related:
http://kerneltrap.org/index.php?q=mailarchive/git/2008/4/16/1450834/thread
http://markmail.org/message/vaois4kkr5ggugqs#query:git%20crlf+page:1+mid:i4flex6vmt5tdala+state:results
http://code.google.com/p/msysgit/issues/detail?id=271
It seems getting line endings right is a bit of a black art.
(I realize that this question probably needs to be expanded, please comment on the places that need expanding)
Are you getting line-ending conflicts? Git has a few configuration properties you can set that change how it handles the end of line characters. I have the following set:
# this makes git NOT attempt to convert line endings on commit and checkout
core.autocrlf=false
# this makes git check if the conversion done by autocrlf would be reversible
# this is probably not required because I do not have autocrlf turned on
core.safecrlf=true
Note that I am on windows, all my coworkers are on windows and I am interfacing with SVN through git-svn. These settings seem to do the trick for me.
(source: codinghorror.com)
Related
I am not very familiar with git as I just use it in the most basic manner. Lately I've been running into this strange behavior which makes no sense to me and causes a huge disturbance in my productivity. For certain branches when I run git pull instead of just getting the latest commits from the remote repository like I expect, I get an ENORMOUS list of modified/deleted/added files as well as an enormous list of untracked files. The branch I am pulling from is our team's master branch. I am just trying to keep my local copy of master in sync. What are these other untracked files showing up as well as these modified files? I didn't touch any of these other files.
What makes the problem worse is that I can't delete these untracked files or anything. I've tried `git clean -fx' and it only removes 3-4 files but still leaves hundreds. At this point I just want to get rid of all of these files, delete the branch, and pull the branch from remote again.
I tried doing the following:
git fetch --all
git reset --hard origin/<remote_branch_name>
but I received an error because Git couldn't create a symbolic link. I am using Git on Windows.
Why is git pull doing this, and what should I do?
EDIT: I was finally able to run the git reset command when I ran my prompt as an admin, but it still doesn't explain this weird git pull behavior.
It seems to me that the 'git pull' action did not complete successfully.
It is possible that you modified some of the files as an admin, and when pulling as non-admin user git tries to modify or delete a file and has no permissions to it.
Therefore you stay in some half baked state.
What do you see when you run git status?
Is there any error in the git pull?
I have had git LFS enabled on my repository for a while and it has always worked perfectly. Recently, I have been having issues where my local files are being replaced with links.
As an example, I have a png file that will no longer open because the file format is not supported. Upon opening the file in notepad, I am presented with this.
version https://git-lfs.github.com/spec/v1
oid sha256:733c51c9ee6f0f395f5f042869307154d6ebf6d5d5e3bc10e2af68a432903bf0
size 5104
Many of my files are being replaced with these links and my programs that are accessing these files are throwing errors as they are unable to read them.
I am working in Windows 10, I have git lfs installed, I am using git-bash on the Windows Cmd line. I believe that when I was installing git-bash, I enabled symbolic links, I am unsure if that could potentially be causing the issue.
If you need more information, please let me know. I really appreciate everyone's help!
These are the pointer files that Git LFS uses to track objects. The fact that you're seeing them means that the proper filters for your repository aren't set up. Run git lfs install within your checkout to install the filters both in your repository and in your ~/.gitconfig.
Once you've done that, you can run git lfs checkout to fix the current repository, and then Git LFS should work normally when you check out a branch. If you modify or replace your ~/.gitconfig file, be sure to keep the filter entries that git lfs install inserted there.
The proper commands to set the options are as follows:
git config filter.lfs.process = "git-lfs filter-process"
git config filter.lfs.smudge = "git-lfs smudge -- %f"
git config filter.lfs.clean = "git-lfs clean -- %f"
It's much easier to invoke git lfs install, though.
I've just updated my Xcode from 6 to 7 (and code from Swift 1.2 to Swift 2.0) and try to create new branch in Xcode. After that I can't push my code to Bitbucket.
Is there a way how can I delete repository from directory and setup Bitbucket again and maybe push to another (a new one) repository? Fix of this problem will be great, but I will be satisfied even with move to another repository.
I had this error in xcode 7.1 on a year old project that was working fine. In my case I have a project with the default local repository created by xcode. For anyone who is not going to re-install and re-setup. It is possible to find out what the dangling command is and fix it from command line.
To find the dangling command Open Terminal from the project directory:
xcrun git status
In my case the status returned:
On branch master
You are currently rebasing.
(all conflicts fixed: run "git rebase --continue")
To fix the problem I used:
xcrun git rebase --skip
In my case I ran git status which revealed that You are currently bisecting. (I was doing a bisect and must had forgotten to reset). I did a git bisect reset and attached the head to my latest commit and it was all fine afterwards.
When I am merging from currentBranchA into branchB, I got conflicts,I didn't want to solve the conflicts immediately and quit the merging process. But when I try to merge again, the Xcode shows "The working copy is currently in the middle of another operation..."
I opened the terminal ，cd to the project directory, and check the git status:
git status
it shows:
On branch currentBranchA
Your branch is up to date with 'origin/currentBranchA'.
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
Just do it as it says. Continue to input
git commit and click Ctrl + C to close the commit message window.
The problem will be zero.
The problem was with installation of GitHub. I had a master repository. After reinstall and resetup everything works like before.
EDIT: For anyone who has a problem with Xcode and GIT I have a best advice. Don't use it. Use for example Source Tree
When you start developing for a living, you are gonna have to use more reliable solution for GIT. Imagine you have 70 branches. Using Source Tree you can easily solve conflicts and other things about working in team. Xcode GIT solution is not reliable and you are gonna be only frustrated.
I'm at a point where I realized I took some actions that were the equivalent of entering a cave without a flashlight. Hopefully this retelling of events will contain an indication of what went wrong.
I began at my project's master branch. I performed a git pull from the remote master (to make sure I had the most recent build), then a git checkout -b newFeature. With this newFeature branch, I made some changes, including adding a 700mb .mp4 file. I then committed my changes with git commit -a -m "New features and a big mp4 file..." I never pushed the changes to the remote. Made some more changes, decided I didn't want them, so I did a git stash at the end of the day.
This morning, I switched to master branch, where I did a git/status. I noticed my local master branch was now ahead of the remote master, which was odd because they should have been exactly the same. I also noticed that when I built my iOS app (from master, NOT newFeature) that the app size was 700mb bigger than it should have been.
Now this part is where I started panicking, so I apologize if the order of events is not completely accurate...
I saw that my .mp4 file was an unstaged file after running git status.
I tried to do a git reset HEAD <file>, which seemed to remove the file, but it still showed up in my builds.
I then tried git rebase, but never got through it because I seemed to hit a loop where all git rebase --continue did was end up at the same place over and over, so I aborted (I've never done a rebase before).
Giving up, I deleted all of my local files (or at least I think I did), restarted my computer (you never know), cloned everything from GitHub... and my builds are still including the large mp4 file.
I cannot seem to find the mp4 file, though it is clearly there when I build the app. I never pushed it to the remote, not that it would have let me anyway due to GitHub's restraints.
Any solutions, bread crumbs, or whatever would be greatly appreciated!! Thanks!
EDIT:
I attempted to go back to the build before I ever made the newFeature branch using git reset --hard , still no luck, as my project will still build with the mp4 file.
Perhaps I could find where this mp4 file is store locally? I can not find it in my project folder.
SOLVED:
See my answer below... long story short, I needed to Clean my build in Xcode (Cmd-shift-K) to remove the MP4 from the build folder.
Try git clean to remove any extra files. You should also check the logs of your build system to find out where this file is getting included.
Of course it's something I should have done right from the get-go. I've read before, "Before building your project, do a Clean on your build" (Cmd-Shift-K in Xcode). After running a disk report on my drive (using JDiskReport), I found the mp4 file cached in Xcode's DerivedData folder in my Library folder. Doing a Clean on the build removed the file from this folder, and no other future builds included it.
I guess I never ran across a time when not performing a Clean was really evident. When I was restarting Xcode, I wrongly assumed any sort of cache clearing would be done then.
So turns out this wasn't a problem with git directly, but with Xcode. I'm not sure if it should be the correct behavior or not, but I will now be run a Clean whenever switching between branches.
I have a remote SVN repository and a local git repository. Using git-svn I have linked git to SVN and am successfully using git svn rebase, git svn dcommit to pull and push to the remote SVN repository.
However, when other people check out my previously-git-edited files with SVN and try to open them in VS2010, they receive a dialog telling them the line endings are inconsistent.
I've read a few things about the core.safecrlf option in git config, but would that fix my issue? I have a number of other people checking in, but we're all running windows - I figured the line endings would be the same?
Would setting core.safecrlf preserve the same type of line ends on checkout and on commit?
I have been dealing with this same issue lately. By default, Git on Windows sets core.autocrlf = true. What happens is that your files are checked out from the SVN repo with CRLF line endings, but are committed with unix-style (LF) line endings. When you dcommit those changes, I believe the files are pushed to the SVN server with the unix-style line endings as well. Now when someone checks out those files using SVN, no line ending conversion is performed.
You can set core.autocrlf = false so that no conversion is done. If you are all working in Windows, you shouldn't have any problems. If you are sharing the SVN repo with *nix users, then it is likely that you'll start having inconsistencies. This is the reason for the autocrlf option. The repos should remain consistent, and since Linux doesn't like to play nicely with CRLF, this autocrlf should be set to true.
Line endings problem is a well-known headache of git-svn. I would recommend to use SmartGit to work with your repository. I respects svn:eol-style value to use correct EOL in Git (translating to it to a corresponding .gitattirbutes value). You may also control svn:eol-style value on pushing to SVN by appropriate changes .gitattirbutes.
If you have an access to the server another approach is possible: just install SubGit into your SVN server. Then a linked Git repository will be created on the server such that every push to it will be automatically translated to SVN and vice versa. It also translates svn:eol-style to .gitattirbutes.
So I would recommend one of these solutions, but not git-svn that is (as I know) painfully slow on Windows.
Here is a GitHub article that describes your choices for handling end of line characters in Git:
https://help.github.com/articles/dealing-with-line-endings
Essentially Git helps convert EOL on different OS's. SVN has similar functionality. You will need to ensure that they are set in a consistent manner.