i got this message because of cloning the svn repo with –no-metadata option. Maybe that’s the case with Your problem too. When cloning it without that option everything is fine. The –no-metadata option is meant to clone an SVN repository when the new git clone is to be come the canonical source in the future. … Read more
You’ll need several steps. supply proper trunk, branches and tags folder names and fetch svn repo: git svn init -t tags -b branches -T trunk https://mysvn.com/svnrepo git svn fetch Since tags in svn are real branches, create git tags from tag branches: git for-each-ref –format=”%(refname:short) %(objectname)” refs/remotes/tags | cut -d / -f 3- | while … Read more
As Nathan said, cleaning up those files (un-tracking them) is the smart move. But if you must ignore tracked files (which is not the native Git way when it comes to ignoring files: Git only ignores non-tracked files), you can setup a process copying the content of files you want to ignore, and restoring on … Read more
I know this question has been answered a while ago, but after reading it, I it might help adding examples of the specific git svn branch command and relate it to a typical workflow. Like kch answered, use git svn branch. Here is a full example, (note the -n for dry-run to test): git svn … Read more
Actually, I found an even better way with the –no-ff option on git merge. All this squash technic I used before is no longer required. My new workflow is now as follows: I have a “master” branch that is the only branch that I dcommit from and that clone the SVN repository (-s assume you … Read more
The output of git branch -a shows that you have a remote-tracking branch called origin/master. Perfectly normal. However, the output of git show-ref master contains 6726b4985107e2ddc7539f95e1a6aba536d35bc6 refs/origin/master which indicates that you most likely ran something like the following low-level command: git update-ref refs/origin/master master This command creates a branch (pointing at the same commit as … Read more
It indicates that you do not have a newline (usually \n, aka LF or CRLF) at the end of file. That is, simply speaking, the last byte (or bytes if you’re on Windows) in the file is not a newline. The message is displayed because otherwise there is no way to tell the difference between … Read more
It came down to a couple of items that I can see right now. git gc –aggressive Opening up file permissions to 777 There has to be something else going on, but this was the things that clearly made the biggest impact.
Both Git (the software) and GitHub (the web service) have a concept called “pull request”, and unfortunately they are not exactly the same thing. Native Git The native Git request-pull command has a very short manual page with the following one-sentence description: Summarizes the changes between two commits to the standard output, and includes the … Read more
check out the git-update-index man page and the –assume-unchanged bit and related. when I have your problem I do this git update-index –assume-unchanged dir-im-removing/ or a specific file git update-index –assume-unchanged config/database.yml