Talk:Git
The Mad Cacti: The instructions on this page don't seem to be the correct way to do things. You are left with a copy of the repository, but without an svn bridge. Most git-svn commands can't be used, just resulting in git eating 100% CPU for half an hour before failing (apparently git svn is INSANELY slow on windows due to the inefficiency of fork emulation). Mining the following promising resources (no success yet):
http://subtlegradient.com/articles/2008/04/22/cloning-a-git-svn-clone.html http://trac.webkit.org/wiki/UsingGitWithWebKit http://wiki.gnucash.org/wiki/Git http://yoush.homelinux.org:8079/tech/git-svn-usage-tips http://utsl.gen.nz/talks/git-svn/intro.html#howto-track-rebuildmeta
NeoTA: You're right.
Looking at http://gitorious.org/subversion (which after all should do the right thing, considering what it is a mirror of!),
I've done the right thing but without understanding what the consequences are. It looks like you can only apply patches to the git repo which I must then pull in order to apply them to svn.
Of course, you can get your own mirror of SVN just by 'git svn clone svn://gilgamesh.hamsterrepublic.com/ohrrpgce/wip' (and 'git svn rebase' for updating. I thought I could avoid loading down the gilgamesh server by importing it into git, but apparently only if you are happy to work mainly without SVN commands (or with two checkouts, one git, one git-svn, where you generate patches using 'git format-patch' on the git version and apply them on the git-svn version and finally 'git svn dcommit' on the git-svn version)
The Mad Cacti: No, it is possible to have clone a repository cloned from a repository cloned from svn and use git-svn. That's what those links were about. I've finally worked out how: you should push remotes/git-svn (which is the default ref for the special svn remote):
git push gitorious : refs/remotes/git-svn:refs/remotes/git-svn
(Where I assume the remote is 'gitorious' and ':' pushes refs/heads/*). I assume there's some way to get git to push that ref automatically.
Pushing remotes/git-svn isn't strictly needed, its absense can be easily worked around. This only sends a normal ref, not all the metadata that git-svn associates with it.
Then, the end user does:
git clone -n git://gitorious.org/ohrrpgce-svn/ohrrpgce-svn.git git config --add remote.origin.fetch remotes/git-svn:remotes/git-svn git svn init svn://gilgamesh.HamsterRepublic.com/ohrrpgce/wip git fetch #get refs/remotes/git-svn git svn fetch #running any git-svn command will rebuild the metadata
Mixing dcommitting straight to svn, fetching from svn, and fetching from the gitorious repository seems to work well though I've done very little testing. So I can fetch from the gitorious repository rather than straight from svn whenever possible. So it'd be useful to keep that fairly up to date, but it's not a problem if it's not.
However, before anyone actually starts using it, I request that the first ~400 missing commits, from before everything was moved to wip/, are added. Apparently there's some way to graft two histories together. It would also be nice if the rel/* branches were included.
NeoTA: Where do I get those first 400 commits, then? (yeah, I know how to do the graft. Not sure how to do a graft where you are adding things to the bottom of the history yet)
rel/* are a possibility (can they be done with tags instead of branches?)
" git push gitorious : refs/remotes/git-svn:refs/remotes/git-svn"
s/gitorious/origin
the above command appears to do... nothing? There's certainly no change in a git checkout I can see; no refs/remotes/git-svn, no git-svn listed in .git/config. Maybe I just find the ordering unclear -- if you don't do that, are the following instructions meant to work around it or not?
I tried the commands, anyway, and eventually it choked: "Last fetched revision of refs/remotes/git-svn was r3319, but we are about to fetch: r425!" reran the same command, got same result.
So I'd want to get that working before trying to do any of the other adjustments.
The Mad Cacti: I assume you would clone the first ~400 commits separately from svn://gilgamesh.HamsterRepublic.com/ohrrpgce/. git-svn lets you specify ranges of revisions to fetch. However I guess this sounds somewhat doomed to fail.
It seems that remote refs are never fetched by default (which makes considerable sense), that's what "git config --add remote.origin.fetch remotes/git-svn:remotes/git-svn" is for and why you didn't see any difference when fetching from gitorious.
I don't know yet how to solve this error message, short of explicitly specifying the correct range of revisions (-rXXXX:HEAD, where XXXX is previously fetched + 1). I didn't have this problem when testing with another repository, so I'd guess that it's related to the folder being moved in r425. Searching for the error message doesn't reveal much beside a bug in a previous version of git.
However, since 'git svn fetch' works for you, it must be possible to make it work for people with a cloned repository.
rel/* are definitely branches, not tags. Also, it would probably make more sense to rename git-svn to trunk or wip or remotes/svn/wip (is that valid, where 'svn' isn't a remote? My sources imply so)
NeoTA: At this point, I'm wondering whether an online svn import was really needed. If we have to fetch svn stuff anyway, we're not saving much bandwidth. When I think about it, the salient point I can see is that an online svn import will provide online branching. Otherwise, you can do all your git-y stuff on a standard 'git svn clone' of svn://gilgamesh.HamsterRepublic.com/ohrrpgce/wip (or just /ohrrpgce/ -- I'm testing this right now), use local branching, checkout the destination branch (eg 'wip') when the major change is done and merge the branch for the change in, then commit back to SVN with dcommit.
If you have a good use case for an online svn import, please inform me. If we can't think of a good one, we should consider removing the gitorious 'ohrrpgce-svn' and simply making this 'git' page a lot better.
The Mad Cacti: I don't know what you mean; perhaps you're confused. Cloning from the gitorious repository is a huge time and bandwidth saver (I don't know how long, you're the only one to have cloned directly from svn) and the way in which I can grab new commits either directly from svn or from gitorious is also great. My steps don't involve recloning all that data. If I attempt to 'git fetch' when I've already gotten additional commits from svn I get:
bash-3.1$ git fetch From git://gitorious.org/ohrrpgce-svn/ohrrpgce-svn ! [rejected] git-svn -> git-svn (non fast forward)
(So, I suppose it's crucial that you do
git config --add remote.origin.fetch remotes/git-svn:remotes/git-svn
and not
git config --add remote.origin.fetch +remotes/git-svn:remotes/git-svn
)
I've found that the "Last fetched revision of refs/remotes/git-svn was rXXXX, but we are about to fetch: r425!" error does not occur again once you successfully 'git svn fetch' once. So far the only way I can find to fetch successfully is to specify an explicit revision:
#run 'git log', find last revision XXXX git svn fetch -rXXXX+1 git svn fetch
And from then on everything works beautifully. I'd like a better solution though.
Also, it turns out that most git-svn operations are only insanely slow on windows and the first time you run them on linux. On windows, 'git svn info' took something like a minute (guessing), now I get just 0.7s.
Anyway, you asked about use cases. Having a canonical git clone seems useful for having something to branch from and collaborating. I assume that if people clone from svn in slightly different ways, all the resultant commits could have different hashes (eg, .../ohrrpgce/wip vs. ohrrpgce/ might mean a different repository id). However, I just realised that 'git svn dcommit' rewrites all the commits it pushes. So maybe it's not safe to push work to a gitorious repository that will later be dcommitted. Hmmm. Maybe one could use an intermediate repository onto which stuff from git is rebased prior to being committed.
I wonder whether I can create a repository for the new HS interpreter where I do branching and merging and occasionally merge work to or from svn and somehow have nothing explode. I might like to combine multiple commits together prior to dcommitting, so as to not flood svn with hundreds of commits. I think I'd like to develop it somewhat independently from the OHR: I expect only a very small amount of OHR-specific code
NeoTA: It's great to know that one of the main reasons I created it is indeed valid :)
"So maybe it's not safe to push work to a gitorious repository that will later be dcommitted." You push to a branch (or get the owner to pull your changes if possible). Then you can review commits and do any rebasing there. Then you 'git checkout master' and 'git merge mybranch' when you're sure everything is as you intended.
BTW: 'rewrites commits'? I don't see this, looking at the man page for git-svn. I see that it either a) rebases after committing all the relevant revisions to SVN, or b) resets after committing[...] SVN, depending on whether there is a difference between SVN head and your working tree or not. This is not a problem: It doesn't change bygone history, only the history which belongs uniquely to you and SVN knows nothing about yet. http://progit.org/book/ch3-6.html , if you haven't read it. Partial commits are pretty ordinary in the Git world -- that's why dcommit allows you to commit to SVN based on any commit, not just HEAD of a particular branch. (please tell me if I'm on the wrong track here, I hope you're not annoyed)
there are some issues relating to using multiple active SVN branches. If you only want multiple git branches (all of which ultimately map to the same SVN branch) that should be unproblematic. 'man git-svn' says about dcommit: 'An optional revision or branch argument may be specified'. So handling multiple svn branches is possible, and even creating them. (checking out ohrrpgce/, it looks like some special attention is needed to checkout the different branches. rel/ are still checked out... but in terms of git, I would say they are not and need not be branches; because of the way git works, storing multiple of the same file is very cheap.) Frankly the layout of ohrrpgce SVN confuses me. rel/ make no sense to me as branches (whether SVN or git), because of their position in the directory hierarchy. Anyway, if you only commit to one SVN branch it should be quite easy.
I think git-svn uses perl, that might be the bottleneck. No idea why it's ridiculously slow on Windows though.
Btw ohrrpgce/ clone vs ohrrpgce/wip clone : 33mb vs 16.7mb (actual working tree is bigger). I'm not sure whether to opt for ohrrpgce/, since a checkout would then be 176mb (inc rel/ games/ tools/ web/ wip/), vs ohrrpgce/wip 40mb (both of these figures include the size of .git dir). Would that work OK for you?
I'll have to look into the fetch workaround. little busy at the moment.
Falling back to reading svninfo.txt[edit]
Bob the Hamster (talk) 10:42, 9 July 2017 (PDT): I am trying to practice with the git-svn bridge. I notice that when I try to compile on my cloned copy, I get a very long delay at "Generating ver.txt" followed by the following:
Generating ver.txt Falling back to reading svninfo.txt WARNING!! Could not determine SVN revision, which will result in RPG files without full version info and could lead to mistakes when upgrading .rpg files. A file called svninfo.txt should have been included with the source code if you downloaded a .zip instead of using svn or git.
Bob the Hamster (talk) 11:41, 9 July 2017 (PDT): I am also unable to git svn dcommit
james@breq:~/src/ohrrpgce$ git svn dcommit Unable to determine upstream SVN information from HEAD history. Perhaps the repository is empty. at /usr/lib/git-core/git-svn line 866.
I already tried: rm -rf .git/svn ; git svn fetch but it did not help.
I currently have two (shop related) commits here https://github.com/bob-the-hamster/ohrrpgce but not sure what I need to do to get them merged upstream to svn
TMC (talk): The long delay and error indicates that git-svn's config isn't set correctly. Make sure you executed all the 'git config' lines here: [1]. You should see the effect of those if you look in .git/config.
Maaaybe it'll be necessary to run rm -rf .git/svn after setting up the config data to get it to work, if you've previously tried to do a git svn fetch. But it shouldn't hurt to run rm.
Bob the Hamster (talk) 08:36, 10 July 2017 (PDT): Ah, yes, I definitely had not fetched all the remote branches. That must have been the problem.