On 2008.10.25 13:29:50 -0700, Warren Harris wrote: > I tried a fetch, but still no luck: > > $ git svn fetch > W: Ignoring error from SVN, path probably does not exist: (175002): RA > layer request failed: REPORT of '/svn/!svn/bc/100': Could not read chunk > size: Secure connection truncated (https://svn) > W: Do not be alarmed at the above message git-svn is just searching > aggressively for old history. > This may take a while on large repositories > r58084 = c01dadf89b552077da132273485e7569d8694518 (trunk) > A ... > r58088 = 7916f3a02ad6c759985bd9fb886423c373a72125 (trunk) > > $ git svn rebase > Unable to determine upstream SVN information from working tree history Means that your current branch is not based on what git-svn has fetched, which is expected when you use "svn init" + "svn fetch" after you already started working. What's the actual relationship between your local history and the history you fetched from svn? If your local stuff started from revision X, which you manually imported from svn, you can just rebase it: git rebase --onto <svn-revision-X> <your-revision-X> If you have a bunch of merges in your local history, you might want to merge your stuff into the svn-based branch instead. When you dcommit, the svn repo will only see one big "do it all" commit though. For that, you would create a graft, so that your first "real" local commit gets the svn revision X commit as its parent. That is, from: S---S---SX---S---S---S (svn) LX--------L---L---L---L (local) You want to go to: S---S---SX---S---S---S (svn) \ LX L---L---L---L (local) Where 'S' means that the commit came from SVN, and L means that it is a "local" commit. SX and LX are the commits that have the same tree attached (same directories/files), but have a different hash due to how they were created. The graft overrides the parent-child relation for the first "L" commit, so that it actually appears as being branched off of SX. And then, you'd merge local into svn, so you get: S---S---SX---S---S---S--M (svn) \ / LX L---L---L---L (local) If possible, go with the rebase though. That at least gives a somewhat reasonable history in the svn repo as well. Also note that when you go with the merge way, make sure that the svn branch is totally uptodate before you merge and that the merge commit is the only one to be dcommitted. Otherwise, funny stuff might happen, and rebase might kick in anyway, I don't exactly remember what git-svn does, but it wasn't pleasant :-) Björn -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
