{"thread":{"id":"9197","subject":"StGIT (or guilt) + git-svn?","startedAt":"2007-07-24T10:20:41Z","lastAt":"2007-07-25T22:25:09Z","messageCount":7,"participants":["Steven Grimm","Steven Walter","Josef Sipek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"48428","messageId":"46A5D279.7060601@midwinter.com","threadId":"9197","inReplyTo":null,"subject":"StGIT (or guilt) + git-svn?","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-07-24T10:20:41Z","receivedAt":"2007-07-24T10:20:41Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Anyone have experience mixing git-svn with either StGIT or guilt? A \ncoworker of mine was asking if he could do local versioning of files he \nhas no intention of committing to svn. He wanted a \".git-svnignore\" kind \nof scheme but I think his use case sounds like the sort of thing StGIT \nand guilt are designed for. What I'm not sure about is whether git-svn \nwill confuse those tools or vice versa. I don't think I've ever seen \nthat combo discussed on the list.\n\n-Steve\n"},{"id":"48445","messageId":"20070724112706.GA9540@dervierte","threadId":"9197","inReplyTo":"46A5D279.7060601@midwinter.com","subject":"Re: StGIT (or guilt) + git-svn?","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2007-07-24T11:27:06Z","receivedAt":"2007-07-24T11:27:06Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Tue, Jul 24, 2007 at 06:20:41PM +0800, Steven Grimm wrote:\n> Anyone have experience mixing git-svn with either StGIT or guilt? A \n> coworker of mine was asking if he could do local versioning of files he \n> has no intention of committing to svn. He wanted a \".git-svnignore\" kind \n> of scheme but I think his use case sounds like the sort of thing StGIT \n> and guilt are designed for. What I'm not sure about is whether git-svn \n> will confuse those tools or vice versa. I don't think I've ever seen \n> that combo discussed on the list.\n> \n> -Steve\n\nWell, I can say that stgit and git-svn in no way interfere with each\nother.  I tend to use stgit to clean up my patch sets before commiting\nthem, and have never had a problem.  Thinking about what the tools do, I\ncan't imagine that it would cause a problem.\n\nThat said, I'm not sure that stgit will help you with \"local versioning\"\nof files (I'm not even sure what you mean).  Perhaps you can elaborate\non this point.\n-- \n-Steven Walter <stevenrwalter@gmail.com>\n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n   -Robert Heinlein\n"},{"id":"48450","messageId":"46A5EE4B.7020905@midwinter.com","threadId":"9197","inReplyTo":"20070724112706.GA9540@dervierte","subject":"Re: StGIT (or guilt) + git-svn?","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-07-24T12:19:23Z","receivedAt":"2007-07-24T12:19:23Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Steven Walter wrote:\n> That said, I'm not sure that stgit will help you with \"local versioning\"\n> of files (I'm not even sure what you mean).  Perhaps you can elaborate\n> on this point.\n>   \n\nHe wants to create some files in his git-svn clone and use git to manage \nthem -- checkpointing his work in progress, backing out changes, etc., \nwithout publishing those files to the svn repository. The files in \nquestion are not already in svn. But he does want to work on other files \nthat *are* in the svn repository, and wants those changes to be \ncommitted back.\n\nSo my assumption was that he would do something like maintain his \nlocal-only changes as StGIT patches that never get committed to git. His \nother changes would get committed from StGIT to git, and from there he'd \ndo his normal git-svn dcommit. Or maybe git-svn dcommit followed by stg \nrebase since git-svn dcommit creates new revision IDs.\n\nIn any event, now that I know it's working successfully for at least one \nperson, I'll point him to stg and he can play with it a bit. Didn't want \nto lead him into a dead end. Thanks!\n\n-Steve\n"},{"id":"48505","messageId":"20070724193915.GA6291@filer.fsl.cs.sunysb.edu","threadId":"9197","inReplyTo":"46A5EE4B.7020905@midwinter.com","subject":"Re: StGIT (or guilt) + git-svn?","fromName":"Josef Sipek","fromEmail":"jsipek@fsl.cs.sunysb.edu","sentAt":"2007-07-24T19:39:16Z","receivedAt":"2007-07-24T19:39:16Z","isPatch":false,"sender":{"key":"jsipek@fsl.cs.sunysb.edu","avatar":null},"body":"On Tue, Jul 24, 2007 at 08:19:23PM +0800, Steven Grimm wrote:\n> Steven Walter wrote:\n> >That said, I'm not sure that stgit will help you with \"local versioning\"\n> >of files (I'm not even sure what you mean).  Perhaps you can elaborate\n> >on this point.\n> >  \n> \n> He wants to create some files in his git-svn clone and use git to manage \n> them -- checkpointing his work in progress, backing out changes, etc., \n> without publishing those files to the svn repository. The files in \n> question are not already in svn. But he does want to work on other files \n> that *are* in the svn repository, and wants those changes to be \n> committed back.\n> \n> So my assumption was that he would do something like maintain his \n> local-only changes as StGIT patches that never get committed to git. His \n> other changes would get committed from StGIT to git, and from there he'd \n> do his normal git-svn dcommit. Or maybe git-svn dcommit followed by stg \n> rebase since git-svn dcommit creates new revision IDs.\n> \n> In any event, now that I know it's working successfully for at least one \n> person, I'll point him to stg and he can play with it a bit. Didn't want \n> to lead him into a dead end. Thanks!\n\nIf I understand your scenario correctly, guilt will work just as well.\n\nJosef 'Jeff' Sipek.\n\n-- \nAll science is either physics or stamp collecting.\n\t\t- Ernest Rutherford\n"},{"id":"48532","messageId":"20070724234817.GA29700@dervierte","threadId":"9197","inReplyTo":"46A5EE4B.7020905@midwinter.com","subject":"Re: StGIT (or guilt) + git-svn?","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2007-07-24T23:48:17Z","receivedAt":"2007-07-24T23:48:17Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Tue, Jul 24, 2007 at 08:19:23PM +0800, Steven Grimm wrote:\n> He wants to create some files in his git-svn clone and use git to manage \n> them -- checkpointing his work in progress, backing out changes, etc., \n> without publishing those files to the svn repository. The files in \n> question are not already in svn. But he does want to work on other files \n> that *are* in the svn repository, and wants those changes to be \n> committed back.\n> \n> So my assumption was that he would do something like maintain his \n> local-only changes as StGIT patches that never get committed to git. His \n> other changes would get committed from StGIT to git, and from there he'd \n> do his normal git-svn dcommit. Or maybe git-svn dcommit followed by stg \n> rebase since git-svn dcommit creates new revision IDs.\n\nYou certainly could do local versioning this way, but it isn't how I\naccomplish the same thing.  I keep another branch on top of my \"public\"\nsvn commits for local stuff.  If I always run git-svn dcommit from the\npublic branch, the local changes will stay local.  After committing, I\njust have to rebase the local branch on onto git-svn.\n-- \n-Steven Walter <stevenrwalter@gmail.com>\n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n   -Robert Heinlein\n"},{"id":"48539","messageId":"46A6EF24.4040606@midwinter.com","threadId":"9197","inReplyTo":"20070724234817.GA29700@dervierte","subject":"Re: StGIT (or guilt) + git-svn?","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-07-25T06:35:16Z","receivedAt":"2007-07-25T06:35:16Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Steven Walter wrote:\n> You certainly could do local versioning this way, but it isn't how I\n> accomplish the same thing.  I keep another branch on top of my \"public\"\n> svn commits for local stuff.  If I always run git-svn dcommit from the\n> public branch, the local changes will stay local.  After committing, I\n> just have to rebase the local branch on onto git-svn.\n\nDo you mix your public and private commits on the private branch, then \ncherry-pick some of them over to the public branch before running \ndcommit? Or do you have some other workflow?\n\nThat was actually my first suggestion to him, but he pointed out (and I \nhad to agree) that that would mean he's always just one mistake away \nfrom publishing his local changes. All it takes is getting interrupted \nfor a moment and mistakenly thinking he already switched to the public \nbranch. He wants some less human-error-prone way to tell the system that \na particular change and/or a particular file is not intended for \npublication, and for the system to just honor that without further human \nintervention.\n\nActually, one could argue that the above isn't a git-svn issue at all. \nYou could reasonably want the same thing from git-push too (and even \nfrom pull, though that'd be trickier.) I guess it'd take the form of \nmarking a commit as local-only, and having the system automatically \nrebase all the local-only commits on top of the public ones.\n\nMaybe a wrapper than maintains a pair of underlying git branches for \neach user-visible branch would work. If you have a branch \"foo\" with \nsome public and some private changes (private ones in lower case here):\n\nA---B---C---D---e---f---g   foo\n            ^ foo-public\n\nNow if you commit a new private revision, it's like normal:\n\nA---B---C---D---e---f---g---h   foo\n            ^ foo-public\n\nBut if you commit a new public revision, we do something like\n\ngit commit\ngit checkout foo-public\ngit cherry-pick foo\ngit checkout foo\ngit rebase foo-public\n\nto get\n\nA---B---C---D---H---e---f---g   foo\n                ^ foo-public\n\nThen, when it comes time to do the push / dcommit, we always switch to \nthe foo-public branch first. We push / dcommit, then checkout foo and \nrebase it on foo-public again (since svn dcommit will leave foo-public \npointing at a different revision.)\n\nThis seems like it should work in the context of git-svn with its \nmostly-linear history. Not sure if it'd fall flat on its face in the \npresence of lots of branching and merging.\n\nI also suspect I've more or less just described StGIT and this would be \na big waste of time to reinvent from scratch.\n\n-Steve\n"},{"id":"48598","messageId":"20070725222509.GA21274@dervierte","threadId":"9197","inReplyTo":"46A6EF24.4040606@midwinter.com","subject":"Re: StGIT (or guilt) + git-svn?","fromName":"Steven Walter","fromEmail":"stevenrwalter@gmail.com","sentAt":"2007-07-25T22:25:09Z","receivedAt":"2007-07-25T22:25:09Z","isPatch":false,"sender":{"key":"stevenrwalter@gmail.com","avatar":"https://avatars.githubusercontent.com/u/79127?v=4"},"body":"On Wed, Jul 25, 2007 at 02:35:16PM +0800, Steven Grimm wrote:\n> Do you mix your public and private commits on the private branch, then \n> cherry-pick some of them over to the public branch before running \n> dcommit? Or do you have some other workflow?\n\nYes, what you describe is what I usually do.\n\n> That was actually my first suggestion to him, but he pointed out (and I \n> had to agree) that that would mean he's always just one mistake away \n> from publishing his local changes. All it takes is getting interrupted \n> for a moment and mistakenly thinking he already switched to the public \n> branch. He wants some less human-error-prone way to tell the system that \n> a particular change and/or a particular file is not intended for \n> publication, and for the system to just honor that without further human \n> intervention.\n\nIf I wanted to be argumentative, you're still only one step from\ndisaster with stgit.  In order to build, you'd have to keep your local\nchanges applied.  If you forgot to pop them before a dcommit, they would\nbe published.\n\n> Actually, one could argue that the above isn't a git-svn issue at all. \n> You could reasonably want the same thing from git-push too (and even \n> from pull, though that'd be trickier.) I guess it'd take the form of \n> marking a commit as local-only, and having the system automatically \n> rebase all the local-only commits on top of the public ones.\n> \n> Maybe a wrapper than maintains a pair of underlying git branches for \n> each user-visible branch would work. If you have a branch \"foo\" with \n> some public and some private changes (private ones in lower case here):\n> \n> A---B---C---D---e---f---g   foo\n>            ^ foo-public\n> \n> Now if you commit a new private revision, it's like normal:\n> \n> A---B---C---D---e---f---g---h   foo\n>            ^ foo-public\n> \n> But if you commit a new public revision, we do something like\n> \n> git commit\n> git checkout foo-public\n> git cherry-pick foo\n> git checkout foo\n> git rebase foo-public\n> \n> to get\n> \n> A---B---C---D---H---e---f---g   foo\n>                ^ foo-public\n> \n> Then, when it comes time to do the push / dcommit, we always switch to \n> the foo-public branch first. We push / dcommit, then checkout foo and \n> rebase it on foo-public again (since svn dcommit will leave foo-public \n> pointing at a different revision.)\n> \n> This seems like it should work in the context of git-svn with its \n> mostly-linear history. Not sure if it'd fall flat on its face in the \n> presence of lots of branching and merging.\n> \n> I also suspect I've more or less just described StGIT and this would be \n> a big waste of time to reinvent from scratch.\n\nThis actually sounds fairly useful, as it's mostly the automation of my\nexisting workflow.  Let me know if you follow up on this.\n-- \n-Steven Walter <stevenrwalter@gmail.com>\n\"A human being should be able to change a diaper, plan an invasion,\nbutcher a hog, conn a ship, design a building, write a sonnet, balance\naccounts, build a wall, set a bone, comfort the dying, take orders,\ngive orders, cooperate, act alone, solve equations, analyze a new\nproblem, pitch manure, program a computer, cook a tasty meal, fight\nefficiently, die gallantly. Specialization is for insects.\"\n   -Robert Heinlein\n"}]}