<div dir="ltr"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 20, 2013 at 1:25 PM, Dan Muresan <span dir="ltr"><<a href="mailto:danmbox@gmail.com" target="_blank">danmbox@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There's also the fact that you can't attach patches to github issues.<br>
<div class="HOEnZb"><div class="h5"><br>
On 9/20/13, IOhannes m zmölnig <<a href="mailto:zmoelnig@iem.at">zmoelnig@iem.at</a>> wrote:<br>
> On 09/20/13 01:38, Paul Davis wrote:<br>
>> it is also much easier for project maintainers to handle pull requests<br>
>> than<br>
>> simple patches, which means that someone having their own fork on github<br>
>> can actually be doing the project a service, rather than seeking to<br>
>> "split"<br>
>> from it.<br>
><br>
> i'm aware of that feature of github and i'm using it myself in both<br>
> directions.<br>
><br>
> nevertheless, personally i only ever "github fork" a project after i<br>
> pulled a clone of the original project to my desktop, worked on it and<br>
> eventually want to submit a pull request.<br>
><br>
> git makes it so easy to handle multiple repositories simultaneously<br>
> (most of my git project have 2-4 remotes) and/or to change the URL of a<br>
> single remote.<br>
><br>
> nevertheless, it's not very important - i only found it slightly strange.<br>
><br>
><br>
> fgamsdr<br>
> IOhannes<br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Linux-audio-dev mailing list<br>
<a href="mailto:Linux-audio-dev@lists.linuxaudio.org">Linux-audio-dev@lists.linuxaudio.org</a><br>
<a href="http://lists.linuxaudio.org/listinfo/linux-audio-dev" target="_blank">http://lists.linuxaudio.org/listinfo/linux-audio-dev</a><br>
</div></div></blockquote></div><br></div>