|
We have an svn repo with 4000 commits, and I've been using git svn for it from the start. My other teammates have only discovered git recently, so we're trying to figure out the best way for them to set up the project under git. We have two options; the first is to check out the project using git svn. Since there are 4000 commits in the repo, we wouldn't be able to check it out in a reasonable amount of time without nuking most of the history. On the other hand, they could clone my repo, but in that case, the svn info would be lost, and it's a huge pain adding svn info when a project wasn't checked out with git svn from the start. Is there some way to combine the two so that we can preserve the history and still have the svn info?
|
#
¿
Jun 8, 2009 07:34
|
|
|
|
| # ¿ May 2, 2024 03:33 |
|
|
We have an svn-hosted project located at http://ourclientsdomain.com/project/trunk/subproject1 (and subproject2 to subproject6 as well). I'm using git-svn. Unfortunately, our client won't give us permission to view trunk, because it has other projects unrelated to ours, so we need to check them out one subproject at a time. Is there a way to check them out under one git repo, such that I only have to use git-svn rebase/dcommit once whenever I change stuff? (As opposed to going through each subproject that was changed and doing stuff from there)
|
|
#
¿
Nov 10, 2009 05:14
|
|
|
What's the best way of working with a project with a number of local-only configuration changes in git? Right now I have a branch that i continually rebase and never commit, but that's kind of a pain. I can't .gitignore them because some of the files have already been versioned. I can git update-index --assume-unchanged them, but git stash fucks things up when I do. Anyone have any other hints?
|
|
#
¿
Aug 31, 2010 06:50
|
|
|
Okay quick question: Normally, git svn will detect and track svn branches fine for me, but I've only partially cloned my svn history. In SVN, it looks something like: code:code:For now, I've just done a separate checkout of the branch, which will make merging kind of a pain. Edit: oh god merging really is a pain 
Argue fucked around with this message at 07:38 on Jun 14, 2011 |
|
#
¿
Jun 14, 2011 04:44
|
|
|
Is there a way to make gitk draw a bit more intelligently? I realize that to git, one parent is as good as another, but when you're using it with git-svn then I think the rule for drawing is a bit clearer--since every commit is tracked by a unique and remote svn branch, you'll always know which commits belong to which branches, so I was hoping I could make it draw each branch as a straight line.
|
|
#
¿
Dec 2, 2011 09:16
|
|
|
I'm doing a git svn clone of a repo, and am trying to clone far back enough to see the branching history. The problem is that now it keeps timing out while fetching a particular revision--it's having trouble because some genius checked in branches/dev/projectName/src/main/menugen/Desktop/Docs/Ray's Music/*.mp3, among a lot of other things. What do I do? Is there a way to make git-svn ignore that folder before I've cloned it? As far as I can tell, an interrupted svn checkout can be resumed by just calling svn update, but calling git svn fetch on an interrupted clone resumes by starting over from the most recently fetched revision. At least, that's what I think is happening here. If I can't ignore that folder, is there a way to at least make it resume the checkout properly?
|
|
#
¿
Sep 20, 2012 08:10
|
|
|
Is it possible to gently caress up an svn mkdir or possibly an svn cp so badly that the commit message on the first commit ever got changed? I'm trying to understand how this scenario that just happened to me could have happened: I use git-svn to work with our project. When I was onboarded, I actually took the time to fetch the entire history, and it worked quite well after that. Yesterday though, things got weird. Another guy's git repository broke when he tried to do a fetch, as it was complaining about bad hashes. Worried, I did a fetch, and although I didn't get that error message, git-svn did decide to fetch everything in the history all over again. When it finished, I checked to see what was happening, and found that I had a duplicate set of commits. They had the same timestamps, authors, everything, with one exception: In the original set of commits, the very first commit had the message "Re-org day". In the duplicate set of commits, which apparently git-svn now considers to be the canonical line, the very first commit had the message "Re-org daysvn mkdir http://ourserver/svn/ourproject/oursubproject". I expect that the reason git fetched everything was because the first commit no longer had the same hash, and that problem of course propagated forward. I just want to know if anyone can fathom a scenario where this was somehow caused by a major goof in issuing a mkdir command.
|
|
#
¿
May 31, 2013 10:19
|
|
|
|
| # ¿ May 2, 2024 03:33 |
|
|
What I'm asking for is probably bordering on sorcery, but our client wants us to make some private modifications to an open source library. They've mirrored the project on SVN, but the real project is on Git. I've used git-svn to check out the project, and now I'm wondering if there was a way to add the real repository as a remote, so that I can easily pull in changes into our private copy. I realize this is probably impossible, especially since the SVN repository doesn't even share the same history as the Git repository, but if anyone has any tips on how to manage this project, I'd greatly appreciate it.
|
|
#
¿
Jun 25, 2013 08:07
|
|