On Tue, Jul 24, 2007 at 08:19:23PM +0800, Steven Grimm wrote: > He wants to create some files in his git-svn clone and use git to manage > them -- checkpointing his work in progress, backing out changes, etc., > without publishing those files to the svn repository. The files in > question are not already in svn. But he does want to work on other files > that *are* in the svn repository, and wants those changes to be > committed back. > > So my assumption was that he would do something like maintain his > local-only changes as StGIT patches that never get committed to git. His > other changes would get committed from StGIT to git, and from there he'd > do his normal git-svn dcommit. Or maybe git-svn dcommit followed by stg > rebase since git-svn dcommit creates new revision IDs. You certainly could do local versioning this way, but it isn't how I accomplish the same thing. I keep another branch on top of my "public" svn commits for local stuff. If I always run git-svn dcommit from the public branch, the local changes will stay local. After committing, I just have to rebase the local branch on onto git-svn. -- -Steven Walter <stevenrwalter@xxxxxxxxx> "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." -Robert Heinlein - 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
