Re: "Forking is a Feature" reactions?

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
[email protected]