On 9/15/10 7:18 PM, Ross Gardler wrote: > > In my opinion the above statements are absolutely correct. That is, the > vast majority of local modifications never make it anywhere near project > maintainers. > > GIT does not, and will not, change this on its own - it's a cultural > issue not a tools issue. In my personal experience, what git *does* change is that it makes it more likely that those local modifications will be maintained in relation to the ongoing development of the project (i.e. "trunk"). Because git allows for multiple remotes to be tracked, the downstream user is able to keep their patch set (or multiple patch sets) up to date by continuously merging changes from the central trunk.
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. 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. Justin --------------------------------------------------------------------- To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
