On 09/16/2015 11:15 AM, Trevor Saunders wrote:
ANd it's not just the kids. As an "old fart" who has used a variety of
mechanisms to manage GCC sources through the decades (including some that
were never officially used), GIT wins hands-down.
and its not just for people who send patches upstrea
On 09/16/2015 10:54 AM, Manuel López-Ibáñez wrote:
On 16 September 2015 at 18:32, Jonathan Wakely wrote:
On 16 September 2015 at 17:20, Manuel López-Ibáñez wrote:
My impression is that right now one can develop GCC with GIT or SVN (people
are submitting GIT patches all the time). After the con
On Wed, Sep 16, 2015 at 10:48:13AM -0600, Jeff Law wrote:
> On 09/16/2015 10:32 AM, Jonathan Wakely wrote:
> >On 16 September 2015 at 17:20, Manuel López-Ibáñez wrote:
> >>My impression is that right now one can develop GCC with GIT or SVN (people
> >>are submitting GIT patches all the time). After
On 16 September 2015 at 18:48, Jeff Law wrote:
>> Yes, I think so. "The kids" these days all want to use git, not svn.
>> That's harder to do because you have to set up git *and* git-svn.
>
> Right. And I find that dealing with the mixture of git and git-svn to be a
> real PITA.
OK, I was not aw
On 16 September 2015 at 18:32, Jonathan Wakely wrote:
> On 16 September 2015 at 17:20, Manuel López-Ibáñez wrote:
>> My impression is that right now one can develop GCC with GIT or SVN (people
>> are submitting GIT patches all the time). After the conversion, only GIT
>> will be possible. Does thi
On 09/16/2015 10:32 AM, Jonathan Wakely wrote:
On 16 September 2015 at 17:20, Manuel López-Ibáñez wrote:
My impression is that right now one can develop GCC with GIT or SVN (people
are submitting GIT patches all the time). After the conversion, only GIT
will be possible. Does this actually lower
On 16 September 2015 at 17:20, Manuel López-Ibáñez wrote:
> My impression is that right now one can develop GCC with GIT or SVN (people
> are submitting GIT patches all the time). After the conversion, only GIT
> will be possible. Does this actually lower the entry barrier and will
> attract contri
On 16/09/15 17:49, paul_kon...@dell.com wrote:
On Sep 16, 2015,@4:38 AM, Richard Biener wrote:
On Tue, Sep 15, 2015@7:09 PM, Florian Weimer wrote:
...
Unlike Subversion branch deletion, Git branch deletion is permanent,
so this might not be the best option.
We could have a 2nd git reposit
On Wed, 16 Sep 2015, paul_kon...@dell.com wrote:
>
> > On Sep 16, 2015, at 4:38 AM, Richard Biener
> > wrote:
> >
> > On Tue, Sep 15, 2015 at 7:09 PM, Florian Weimer wrote:
> >> ...
> >> Unlike Subversion branch deletion, Git branch deletion is permanent,
> >> so this might not be the best op
> On Sep 16, 2015, at 4:38 AM, Richard Biener
> wrote:
>
> On Tue, Sep 15, 2015 at 7:09 PM, Florian Weimer wrote:
>> ...
>> Unlike Subversion branch deletion, Git branch deletion is permanent,
>> so this might not be the best option.
>
> We could have a 2nd git repository just containing dele
On Tue, Sep 15, 2015 at 7:09 PM, Florian Weimer wrote:
> * Jason Merrill:
>
>> There are lots of ancient branches and tags in the SVN repository that
>> are no longer interesting, and it would be nice not to have them
>> cluttering up the lists and default fetch set.
>
> Just one minor comment: Du
On Tue, Sep 15, 2015 at 7:09 PM, Florian Weimer wrote:
> * Jason Merrill:
>
>> There are lots of ancient branches and tags in the SVN repository that
>> are no longer interesting, and it would be nice not to have them
>> cluttering up the lists and default fetch set.
>
> Just one minor comment: Du
* Jason Merrill:
> There are lots of ancient branches and tags in the SVN repository that
> are no longer interesting, and it would be nice not to have them
> cluttering up the lists and default fetch set.
Just one minor comment: Due to the way Git branches work, this
decision can be deferred to
On Tue, 15 Sep 2015, Jason Merrill wrote:
> There are lots of ancient branches and tags in the SVN repository that are no
> longer interesting, and it would be nice not to have them cluttering up the
> lists and default fetch set.
>
> The options I see for each branch or tag are:
> 1) Keep them a
14 matches
Mail list logo
