On 9/16/10 10:34 AM, Eric Evans wrote: > On Thu, 2010-09-16 at 09:31 -0400, Justin Edelson wrote: >> I can say with some confidence that without the git svn workflow, I >> would not be an Apache committer. I would have done exactly what I'd >> done for years prior - svn export from a tag, svn import, and patch. >> Maybe re-export and reapply my patches when a new release came out >> (but that was a pain in the ass, so didn't happen that frequently). >> But submitting my patches back was frequently too difficult because >> they were against a tag, not trunk. And even if they were against >> trunk, they were against trunk at a certain revision, which inevitably >> was not HEAD. > > Git-svn is awesome (I use it), but since a Git merge cannot be > represented in Subversion, you aren't able to safely pull/merge/push > with other Git repos. It basically becomes a very fancy patch manager > when used this way. AFAICT, the way you workaround this is to work in a different branch than the one connected to svn (typically master). The master branch of my git repository which is connected to svn.apache.org is basically pristene - whenever I'm ahead of trunk, it is because I'm about to commit something. If I'm working on something significant, I branch, work on the branch, and then remerge (and delete the branch). That branch can be pushed and pulled.
I can't say that I have exercised this fully and I don't claim to be a git expert, so YMMV. Justin > >> Adopting git/git svn did a lot of things, but mostly it gave me the >> ability to contribute back my patches while proceeding with >> development of a branched version containing my full patch set. For >> the project, this lead to smaller, easier to understand patch >> submissions(and, eventually, a new committer!). >> >> IMHO, I think the subject of the original blog post in this thread is >> just wrong. Forking isn't a feature. Merging is a feature. > > Good point. > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
