[ditz-talk] a modest proposal for collaboration
nicolas.pouillard at gmail.com
Tue Apr 15 09:06:00 EDT 2008
Excerpts from William Morgan's message of Sun Apr 13 23:55:21 +0200 2008:
> Reformatted excerpts from nicolas.pouillard's message of 2008-04-13:
> > That's very good plan! -- Even if it took me a lot more time to setup
> > all these branches that effectively writing the code :(
> I think that I'll create topic branches for people the first time, but
> ask that subsequent changes be published on branches from master. I
> don't want to set the bar too high.
> > I've made these three branches and request for merges.
> Thanks! Tasks and shell-completion have been merged into edge.
> The hooks branch contains some commits that are not hook-related (the
> bugs/*.yaml changes, the prettification change, and the final merge
> against edge that the prettification change requires because of the
> recursive directory stuff.)
> The entire bugs directory has been moved to the "bugs" branch, so that's
> a delete+modify conflict, which is easy enough for me to resolve. :)
I'm not fond of putting bugs in another branch, I it defeats the purpose of
this kind of system, because it turns to centralize bugs instead of tying to
the related topic branch. However that's another debate and while ditz let me
do otherwise I'm happy.
> But the final commit in the branch (the merge) means I won't be able to
> apply the hooks changes to master without applying the recursive
> directory search changes as well.
> Should I apply anyways? I don't want to be overly strict about this type
> of thing. You tell me.
As you like, either you merge the 'hook' branch and resolve conflicts or I
merge them into my edge branch and you pull my edge branch merged and
Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080415/b10b4976/attachment.bin
More information about the ditz-talk