Re: "Forking is a Feature" reactions?

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.
>