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. > 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. -- Eric Evans eev...@rackspace.com --------------------------------------------------------------------- To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
