On Sat, Sep 21, 2019 at 05:32:03PM -0400, Jason Merrill wrote:
> On Sat, Sep 21, 2019 at 2:18 PM Segher Boessenkool
> wrote:
> >
> > On Thu, Sep 19, 2019 at 03:29:27PM -0400, Jason Merrill wrote:
> > > I suppose we also need to decide what form we want to use for the
> > > equivalent of gcc.gnu.or
On Sat, Sep 21, 2019 at 2:18 PM Segher Boessenkool
wrote:
>
> On Thu, Sep 19, 2019 at 03:29:27PM -0400, Jason Merrill wrote:
> > I suppose we also need to decide what form we want to use for the
> > equivalent of gcc.gnu.org/rN. I figure it needs to be some prefix
> > followed by a "commit-is
On 9/21/19 2:18 PM, Segher Boessenkool wrote:
On Thu, Sep 19, 2019 at 03:29:27PM -0400, Jason Merrill wrote:
I suppose we also need to decide what form we want to use for the
equivalent of gcc.gnu.org/rN. I figure it needs to be some prefix
followed by a "commit-ish" (hash, tag, etc.). P
On Thu, Sep 19, 2019 at 03:29:27PM -0400, Jason Merrill wrote:
> I suppose we also need to decide what form we want to use for the
> equivalent of gcc.gnu.org/rN. I figure it needs to be some prefix
> followed by a "commit-ish" (hash, tag, etc.). Perhaps "g:" as the
> prefix, so
>
> gcc.gnu.
On Wed, Aug 14, 2019 at 2:14 PM Jason Merrill wrote:
> On Mon, Aug 5, 2019 at 2:22 PM Jason Merrill wrote:
> > On 8/5/19 11:34 AM, Jakub Jelinek wrote:
> > > On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote:
> > >> I agree. But for those who want a monotonically increasing
> > >> id
> On Aug 24, 2019, at 12:30 AM, Joseph Myers wrote:
>
> On Fri, 23 Aug 2019, Maxim Kuvyrkov wrote:
>
>> I propose that we switch to gcc-pretty.git repository, because it has
>> accurate Committer and Author fields. Developer names and email
>> addresses are extracted from source history, and
On Fri, 23 Aug 2019, Maxim Kuvyrkov wrote:
> I propose that we switch to gcc-pretty.git repository, because it has
> accurate Committer and Author fields. Developer names and email
> addresses are extracted from source history, and accurately track people
> changing companies, email addresses,
> On Aug 6, 2019, at 12:32 PM, Maxim Kuvyrkov wrote:
>
...
> I've setup uploads and updates of fully converted GCC history (all branches
> and all tags) in 3 flavors. These will be updated roughly hourly.
>
> 1. https://git-us.linaro.org/people/maxim-kuvyrkov/gcc-pretty.git/
> This is a fresh
On Mon, Aug 5, 2019 at 2:22 PM Jason Merrill wrote:
> On 8/5/19 11:34 AM, Jakub Jelinek wrote:
> > On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote:
> >> I agree. But for those who want a monotonically increasing
> >> identifier, there's already one in git: CommitDate. In the discus
> On Aug 5, 2019, at 11:24 AM, Maxim Kuvyrkov wrote:
>
>
>> On Aug 2, 2019, at 11:41 AM, Maxim Kuvyrkov
>> wrote:
>>
>>> On Aug 1, 2019, at 11:43 PM, Jason Merrill wrote:
>>>
> ...
Unfortunately, current mirror does not and could not account for rewrites
of SVN commit log message
On 8/5/19 11:34 AM, Jakub Jelinek wrote:
On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote:
I agree. But for those who want a monotonically increasing
identifier, there's already one in git: CommitDate. In the discussion
of this issue four years ago,
While commit date is monotoni
On Aug 2, 2019, at 4:06 AM, Richard Biener wrote:
>
> IMHO voting is bike-shedding.
>
> Those who do the work decide. _They_ may ask questions _and_ decide whether
> to listen to the answer.
I'd tend to agree. I also think the recent conversion work is a fine solution,
and that my preference
On 05/08/2019 16:34, Jakub Jelinek wrote:
On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote:
I agree. But for those who want a monotonically increasing
identifier, there's already one in git: CommitDate. In the discussion
of this issue four years ago,
While commit date is monoton
On Mon, Aug 05, 2019 at 11:20:09AM -0400, Jason Merrill wrote:
> I agree. But for those who want a monotonically increasing
> identifier, there's already one in git: CommitDate. In the discussion
> of this issue four years ago,
While commit date is monotonically increasing, it has the problem th
On Mon, Aug 5, 2019 at 9:20 AM Martin Liška wrote:
> Based on the IRC discussion with Jakub, there's missing key element of the
> transition.
> Jakub requests to have a monotonically increasing revisions (aka rXXX) to
> be assigned
> for the future git revisions. These will be linked from b
On 8/3/19 12:31 AM, Jason Merrill wrote:
> On Fri, Aug 2, 2019 at 7:35 AM Martin Liška wrote:
>>
>> On 8/2/19 1:06 PM, Richard Biener wrote:
>>> On Fri, Aug 2, 2019 at 1:01 PM Martin Liška wrote:
On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
>> On Aug 2, 2019, at 1:26 PM, Martin Liška
> On Aug 2, 2019, at 11:41 AM, Maxim Kuvyrkov wrote:
>
>> On Aug 1, 2019, at 11:43 PM, Jason Merrill wrote:
>>
...
>>> Unfortunately, current mirror does not and could not account for rewrites
>>> of SVN commit log messages. For trunk the histories of diverge in 2008 due
>>> to commit mess
On Fri, Aug 2, 2019 at 7:35 AM Martin Liška wrote:
>
> On 8/2/19 1:06 PM, Richard Biener wrote:
> > On Fri, Aug 2, 2019 at 1:01 PM Martin Liška wrote:
> >>
> >> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
> On Aug 2, 2019, at 1:26 PM, Martin Liška wrote:
>
> On 8/2/19 10:41 AM, Maxi
On Fri, Aug 02, 2019 at 05:14:20PM +0300, Maxim Kuvyrkov wrote:
> > On Aug 2, 2019, at 11:35 AM, Maxim Kuvyrkov
> > wrote:
> >> On Jul 22, 2019, at 12:05 PM, Maxim Kuvyrkov
> >> wrote:
> > 3. Conversion is now feature-complete. The scripts re-write author and
> > committer fields, as well as
> On Aug 2, 2019, at 2:06 PM, Richard Biener wrote:
>
> On Fri, Aug 2, 2019 at 1:01 PM Martin Liška wrote:
>>
>> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
On Aug 2, 2019, at 1:26 PM, Martin Liška wrote:
On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
> In the end, I don't care mu
On Fri, Aug 02, 2019 at 01:06:12PM +0200, Richard Biener wrote:
> 1) Stay with SVN
> 2) Switch to the existing GIT mirror
> 3) Wait for ERS to complete his conversion to GIT
> 4) Use the existing new conversion to GIT fixing authors and commit messages
> 5) I don't care
> 6) I don't care as long as
> On Aug 2, 2019, at 11:35 AM, Maxim Kuvyrkov wrote:
>
>> On Jul 22, 2019, at 12:05 PM, Maxim Kuvyrkov
>> wrote:
>>
> ...
> As far as GCC conversion goes, below is what I plan to do and what not to
> do. This is based on comments from everyone in this thread:
>
> 1. Construc
On 8/2/19 1:06 PM, Richard Biener wrote:
> On Fri, Aug 2, 2019 at 1:01 PM Martin Liška wrote:
>>
>> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
On Aug 2, 2019, at 1:26 PM, Martin Liška wrote:
On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
> In the end, I don't care much to which versi
On Fri, Aug 2, 2019 at 1:01 PM Martin Liška wrote:
>
> On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
> >> On Aug 2, 2019, at 1:26 PM, Martin Liška wrote:
> >>
> >> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
> >>> In the end, I don't care much to which version of the repo we switch, as
> >>> long as w
On 8/2/19 12:54 PM, Maxim Kuvyrkov wrote:
>> On Aug 2, 2019, at 1:26 PM, Martin Liška wrote:
>>
>> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
>>> In the end, I don't care much to which version of the repo we switch, as
>>> long as we switch.
>>
>> Hi Maxim.
>>
>> I really appreciate that you've be
> On Aug 2, 2019, at 1:26 PM, Martin Liška wrote:
>
> On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
>> In the end, I don't care much to which version of the repo we switch, as
>> long as we switch.
>
> Hi Maxim.
>
> I really appreciate that you've been working on that. Same as you I would
> like
On 8/2/19 10:41 AM, Maxim Kuvyrkov wrote:
> In the end, I don't care much to which version of the repo we switch, as long
> as we switch.
Hi Maxim.
I really appreciate that you've been working on that. Same as you I would like
to see
any change that will lead to a git repository.
I have couple
On Fri, Aug 2, 2019 at 10:41 AM Maxim Kuvyrkov
wrote:
>
> > On Aug 1, 2019, at 11:43 PM, Jason Merrill wrote:
> >
> > On Mon, Jul 22, 2019 at 5:05 AM Maxim Kuvyrkov
> > wrote:
> >>
> >>> On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov
> >>> wrote:
> >>>
> On Jul 16, 2019, at 3:34 PM, Jason Me
> On Aug 1, 2019, at 11:43 PM, Jason Merrill wrote:
>
> On Mon, Jul 22, 2019 at 5:05 AM Maxim Kuvyrkov
> wrote:
>>
>>> On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov
>>> wrote:
>>>
On Jul 16, 2019, at 3:34 PM, Jason Merrill wrote:
On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
> On Jul 22, 2019, at 12:05 PM, Maxim Kuvyrkov
> wrote:
>
...
As far as GCC conversion goes, below is what I plan to do and what not to
do. This is based on comments from everyone in this thread:
1. Construct GCC's git repo from SVN using same settings as current git
On Mon, Jul 22, 2019 at 5:05 AM Maxim Kuvyrkov
wrote:
>
> > On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov
> > wrote:
> >
> >> On Jul 16, 2019, at 3:34 PM, Jason Merrill wrote:
> >>
> >> On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
> >> wrote:
> >>>
> >>> Hi Everyone,
> >>>
> >>> I've been swa
> On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov wrote:
>
>> On Jul 16, 2019, at 3:34 PM, Jason Merrill wrote:
>>
>> On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
>> wrote:
>>>
>>> Hi Everyone,
>>>
>>> I've been swamped with other projects for most of June, which gave me time
>>> to digest a
> On Jul 16, 2019, at 5:14 PM, Maxim Kuvyrkov wrote:
>
>> On Jul 16, 2019, at 3:34 PM, Jason Merrill wrote:
>>
...
>>
>>> b. Re-write tags/ branches into annotated tags. Note that tags/* are
>>> included into history of several branches via merge or copy commits, so we
>>> would need to re-
> On Jul 16, 2019, at 3:34 PM, Jason Merrill wrote:
>
> On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
> wrote:
>>
>> Hi Everyone,
>>
>> I've been swamped with other projects for most of June, which gave me time
>> to digest all the feedback I've got on GCC's conversion from SVN to Git.
>>
On Tue, Jul 16, 2019 at 12:18 PM Maxim Kuvyrkov
wrote:
>
> Hi Everyone,
>
> I've been swamped with other projects for most of June, which gave me time to
> digest all the feedback I've got on GCC's conversion from SVN to Git.
>
> The scripts have heavily evolved from the initial version posted he
Hi Everyone,
I've been swamped with other projects for most of June, which gave me time to
digest all the feedback I've got on GCC's conversion from SVN to Git.
The scripts have heavily evolved from the initial version posted here. They
have become fairly generic in that they have no implied k
On 07/06/2019 00:50, Ian Lance Taylor wrote:
> On Thu, Jun 6, 2019 at 4:41 PM Joseph Myers wrote:
>>
>> On Thu, 6 Jun 2019, Richard Earnshaw (lists) wrote:
>>
For email addresses, I think that using @gcc.gnu.org would be the best
approach for people that have such accounts, rather than a
On Thu, Jun 6, 2019 at 4:41 PM Joseph Myers wrote:
>
> On Thu, 6 Jun 2019, Richard Earnshaw (lists) wrote:
>
> > > For email addresses, I think that using @gcc.gnu.org would be the best
> > > approach for people that have such accounts, rather than an employer
> > > address from an arbitrary point
On Thu, 6 Jun 2019, Richard Earnshaw (lists) wrote:
> > For email addresses, I think that using @gcc.gnu.org would be the best
> > approach for people that have such accounts, rather than an employer
> > address from an arbitrary point in time.
>
> Or @gnu.org for accounts that pre-date the switc
On Wed, 5 Jun 2019, Jason Merrill wrote:
> > I think failing to credit (by name and email address) the person implied
> > by the commit metadata, in the absence of positive evidence (such as a
> > ChangeLog entry) for the change being authored by someone else, is just
> > wrong, in the same way it
On 05/06/2019 19:04, Jason Merrill wrote:
> On 6/3/19 6:33 PM, Joseph Myers wrote:
>> On Sun, 2 Jun 2019, Segher Boessenkool wrote:
>>
> Git has an identity (well, two) _per commit_, and there is no way
> you can
> reconstruct people's prefered name and email address (at any point
>
On 6/3/19 6:33 PM, Joseph Myers wrote:
On Sun, 2 Jun 2019, Segher Boessenkool wrote:
Git has an identity (well, two) _per commit_, and there is no way you can
reconstruct people's prefered name and email address (at any point in time,
for every commit separately) correctly. IMO it is much bett
On Mon, Jun 03, 2019 at 10:33:17PM +, Joseph Myers wrote:
> Where a person used different names over time, there's no generally
> applicable rule for whether they'd prefer the latest version or the
> version used at the time to be used in reference to past commits, and I
> think using the mo
On Sun, 2 Jun 2019, Segher Boessenkool wrote:
> > > Git has an identity (well, two) _per commit_, and there is no way you can
> > > reconstruct people's prefered name and email address (at any point in
> > > time,
> > > for every commit separately) correctly. IMO it is much better to not even
>
On Fri, May 31, 2019 at 12:05:41AM +, Joseph Myers wrote:
> On Wed, 29 May 2019, Segher Boessenkool wrote:
>
> > On Wed, May 29, 2019 at 12:53:30AM +, Joseph Myers wrote:
> > > On Fri, 24 May 2019, Segher Boessenkool wrote:
> > >
> > > > IMO the best we can do is use what we already have:
On Wed, 29 May 2019, Segher Boessenkool wrote:
> On Wed, May 29, 2019 at 12:53:30AM +, Joseph Myers wrote:
> > On Fri, 24 May 2019, Segher Boessenkool wrote:
> >
> > > IMO the best we can do is use what we already have: what CVS or SVN used
> > > as the committer identity. *That* info is *co
On Wed, May 29, 2019 at 12:53:30AM +, Joseph Myers wrote:
> On Fri, 24 May 2019, Segher Boessenkool wrote:
>
> > IMO the best we can do is use what we already have: what CVS or SVN used
> > as the committer identity. *That* info is *correct* at least.
>
> CVS and SVN have a local identity.
On Fri, 24 May 2019, Segher Boessenkool wrote:
> IMO the best we can do is use what we already have: what CVS or SVN used
> as the committer identity. *That* info is *correct* at least.
CVS and SVN have a local identity. git has a global identity. I consider
it simply *incorrect* to put a loc
Hi Everyone,
What can I say, I was too optimistic about how easy it would be to convert
GCC's svn repo to git one branch at a time. After 2 more weeks and several
re-writes of the scripts I now know more about GCC's svn history than I would
ever wanted.
The prize for most complicated branch h
* Segher Boessenkool:
> On Thu, May 23, 2019 at 10:33:28PM +, Joseph Myers wrote:
>> On Tue, 21 May 2019, Segher Boessenkool wrote:
>>
>> > > I think having author names and email addresses is a basic requirement
>> > > of
>> > > any reasonable repository conversion
>> >
>> > Yes, and they
On Thu, May 23, 2019 at 10:33:28PM +, Joseph Myers wrote:
> On Tue, 21 May 2019, Segher Boessenkool wrote:
>
> > > I think having author names and email addresses is a basic requirement of
> > > any reasonable repository conversion
> >
> > Yes, and they should be the same as they were in the
On Tue, 21 May 2019, Segher Boessenkool wrote:
> > I think having author names and email addresses is a basic requirement of
> > any reasonable repository conversion
>
> Yes, and they should be the same as they were in the original repository.
That's what the "changelogs" feature in reposurgeon
Hi Joseph,
On Mon, May 20, 2019 at 10:42:45PM +, Joseph Myers wrote:
> (SVN will remain
> readonly, just as the old CVS repository remains available readonly).
> That the git-svn mirror is useful for many purposes for which people want
> to use git also provides a clear argument against nee
On 21/05/2019 15:44, Jeff Law wrote:
> On 5/21/19 8:24 AM, Richard Earnshaw (lists) wrote:
>> On 20/05/2019 23:42, Joseph Myers wrote:
>>
>>> I'm not particularly concerned with distinguishing between different names
>>> and email addresses for an author depending on when or in what capacity
>>>
On 5/21/19 8:24 AM, Richard Earnshaw (lists) wrote:
> On 20/05/2019 23:42, Joseph Myers wrote:
>
>> I'm not particularly concerned with distinguishing between different names
>> and email addresses for an author depending on when or in what capacity
>> they contributed a change, or with the case
On 20/05/2019 23:42, Joseph Myers wrote:
> I'm not particularly concerned with distinguishing between different names
> and email addresses for an author depending on when or in what capacity
> they contributed a change, or with the cases where a patch was committed
> for someone else and SVN s
On Fri, 17 May 2019, Jason Merrill wrote:
> Thanks for looking into this. My feeling has been that, if we give up
> on reposurgeon, there's no need to start a new conversion at all: we
> can just switch the current mirror over to being the primary
> repository with some minor surgery (e.g. using
On Fri, 17 May 2019, Richard Sandiford wrote:
> We're not starting from scratch on that though. The public git
> (semi-)mirror has been going for a long time, so IMO we should just
> inherit the policies for that. (Like you say, forced pushed are
> restricted to the user namespace.) Policies ca
On Mon, May 20, 2019 at 04:29:10PM +0200, Jakub Jelinek wrote:
> On Mon, May 20, 2019 at 04:26:45PM +0200, Andreas Schwab wrote:
> > On Mai 20 2019, Florian Weimer wrote:
> >
> > > If GCC policy is to reject merge commits, a command similar to
> > > “git log --pretty=oneline | wc -l” gives someth
On Mai 20 2019, Jakub Jelinek wrote:
> On Mon, May 20, 2019 at 04:26:45PM +0200, Andreas Schwab wrote:
>> On Mai 20 2019, Florian Weimer wrote:
>>
>> > If GCC policy is to reject merge commits, a command similar to
>> > “git log --pretty=oneline | wc -l” gives something that is very
>>
>> git
On Mon, May 20, 2019 at 04:26:45PM +0200, Andreas Schwab wrote:
> On Mai 20 2019, Florian Weimer wrote:
>
> > If GCC policy is to reject merge commits, a command similar to
> > “git log --pretty=oneline | wc -l” gives something that is very
>
> git rev-list HEAD | wc -l
That is still in the 1.3
On Mai 20 2019, Florian Weimer wrote:
> If GCC policy is to reject merge commits, a command similar to
> “git log --pretty=oneline | wc -l” gives something that is very
git rev-list HEAD | wc -l
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4
On Mon, May 20, 2019 at 03:56:35PM +0200, Florian Weimer wrote:
> * Andrew Pinski:
>
> > On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
> > wrote:
>
> >> Git can bisect automatically just fine, there is no upside to doing things
> >> manually. In git there are various handy ways of referri
On Mon, May 20, 2019 at 03:56:35PM +0200, Florian Weimer wrote:
> If GCC policy is to reject merge commits, a command similar to
> “git log --pretty=oneline | wc -l” gives something that is very
> much like a Subversion revision number, in the sense that it matches
> the commit ordering and that th
* Andrew Pinski:
> On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
> wrote:
>> Git can bisect automatically just fine, there is no upside to doing things
>> manually. In git there are various handy ways of referring to commits; you
>> can say master@{3 days ago} for example, or zut@{31}
On 5/19/19 10:06 PM, Marek Polacek wrote:
> On Sun, May 19, 2019 at 01:00:45PM -0700, Andrew Pinski wrote:
>> On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
>> wrote:
>>>
>>> On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
On Sun, May 19, 2019 at 03:11:08AM -0500, Segher B
On Sun, May 19, 2019 at 01:00:45PM -0700, Andrew Pinski wrote:
> On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
> wrote:
> >
> > On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
> > > On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> > > > On Sun, May 19, 201
On Sun, May 19, 2019 at 12:54 PM Segher Boessenkool
wrote:
>
> On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
> > On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> > > On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> > > > Do we really need a comm
On Sun, May 19, 2019 at 03:21:01PM -0400, Marek Polacek wrote:
> On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> > On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> > > Do we really need a commit integer numbers after the transition? I know
> > > we're used to i
On Mai 19 2019, Marek Polacek wrote:
> On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
>> On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
>> > Do we really need a commit integer numbers after the transition? I know
>> > we're used to it.
>> > But git commit hash
On Sun, May 19, 2019 at 03:11:08AM -0500, Segher Boessenkool wrote:
> On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> > Do we really need a commit integer numbers after the transition? I know
> > we're used to it.
> > But git commit hash provides that same.
>
> Revision numbers ar
On Sun, May 19, 2019 at 09:35:45AM +0200, Martin Liška wrote:
> Do we really need a commit integer numbers after the transition? I know
> we're used to it.
> But git commit hash provides that same.
Revision numbers are nice short text strings, and from a revision number
you can see approximately
On 5/17/19 2:39 PM, Jakub Jelinek wrote:
On Fri, May 17, 2019 at 02:22:47PM +0200, Martin Liška wrote:
On 5/17/19 1:06 AM, Joseph Myers wrote:
That repository
represents what I consider the collaboratively built consensus on such
things as the desired author map (including handling of the ambig
On 5/17/19 4:59 PM, Maxim Kuvyrkov wrote:
On May 17, 2019, at 3:22 PM, Martin Liška wrote:
On 5/17/19 1:06 AM, Joseph Myers wrote:
That repository
represents what I consider the collaboratively built consensus on such
things as the desired author map (including handling of the ambiguous
author
On Fri, May 17, 2019 at 3:51 PM Segher Boessenkool
wrote:
> Yes -- one of the problems I have with the current git-svn mirror is that
> it doesn't have any of the SVN branches under ibm/ as separate Git branches.
> It looks like Maxim's scripts will handle this; the conversion hasn't
> reached tho
I hope this isn't too much of a thread drift but I was wondering if,
after the Git conversion, will the GCC repo look like a 'normal' GIT
repo with the main line sources on the master branch?
I.e. right now instead of a simple clone, the GCC Wiki says to use a
sequence of git init/config/fetch/che
On Fri, May 17, 2019 at 09:18:53AM +0100, Richard Sandiford wrote:
> Joseph Myers writes:
> > On Thu, 16 May 2019, Maxim Kuvyrkov wrote:
> >> With git, we can always split away unneeded history by removing
> >> unnecessary branches and tags and re-packing the repo. We can equally
> >> easily br
> On May 17, 2019, at 4:07 PM, Jason Merrill wrote:
>
> On Tue, May 14, 2019 at 12:11 PM Maxim Kuvyrkov
> wrote:
>>
>> This patch adds scripts to contrib/ to migrate full history of GCC's
>> subversion repository to git. My hope is that these scripts will finally
>> allow GCC project to migr
> On May 17, 2019, at 3:22 PM, Martin Liška wrote:
>
> On 5/17/19 1:06 AM, Joseph Myers wrote:
>> That repository
>> represents what I consider the collaboratively built consensus on such
>> things as the desired author map (including handling of the ambiguous
>> author name), which directorie
> On May 17, 2019, at 2:06 AM, Joseph Myers wrote:
>
> On Tue, 14 May 2019, Maxim Kuvyrkov wrote:
>
>> The scripts convert svn history branch by branch. They rely on git-svn
>> on convert individual branches. Git-svn is a good tool for converting
>> individual branches. It is, however, eith
On Tue, May 14, 2019 at 12:11 PM Maxim Kuvyrkov
wrote:
>
> This patch adds scripts to contrib/ to migrate full history of GCC's
> subversion repository to git. My hope is that these scripts will finally
> allow GCC project to migrate to Git.
Thanks for looking into this. My feeling has been t
On Fri, May 17, 2019 at 02:22:47PM +0200, Martin Liška wrote:
> On 5/17/19 1:06 AM, Joseph Myers wrote:
> > That repository
> > represents what I consider the collaboratively built consensus on such
> > things as the desired author map (including handling of the ambiguous
> > author name), which
On 5/17/19 1:06 AM, Joseph Myers wrote:
> That repository
> represents what I consider the collaboratively built consensus on such
> things as the desired author map (including handling of the ambiguous
> author name), which directories represent branches and tags, and what tags
> should be kep
On 5/17/19 12:04 AM, Jonathan Wakely wrote:
> On 16/05/19 13:07 -0600, Jeff Law wrote:
>> On 5/16/19 12:36 PM, Ramana Radhakrishnan wrote:
>>> On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
>>> wrote:
> On May 16, 2019, at 7:22 PM, Jeff Law wrote:
>
> On 5/15/19 5:19 AM, Richard
Joseph Myers writes:
> On Thu, 16 May 2019, Maxim Kuvyrkov wrote:
>
>> Let's avoid mixing the two discussions: (1) converting svn repo to git
>> (and getting community consensus to switch to git) and (2) deciding on
>> which branches to keep in the new repo.
>>
>> With git, we can always split
On Thu, 16 May 2019, Maxim Kuvyrkov wrote:
> Let's avoid mixing the two discussions: (1) converting svn repo to git
> (and getting community consensus to switch to git) and (2) deciding on
> which branches to keep in the new repo.
>
> With git, we can always split away unneeded history by remov
On Tue, 14 May 2019, Maxim Kuvyrkov wrote:
> The scripts convert svn history branch by branch. They rely on git-svn
> on convert individual branches. Git-svn is a good tool for converting
> individual branches. It is, however, either very slow at converting the
> entire GCC repo, or goes int
On 16/05/19 13:07 -0600, Jeff Law wrote:
On 5/16/19 12:36 PM, Ramana Radhakrishnan wrote:
On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
wrote:
On May 16, 2019, at 7:22 PM, Jeff Law wrote:
On 5/15/19 5:19 AM, Richard Biener wrote:
For the official converted repo do we really want all (ol
On 5/16/19 12:36 PM, Ramana Radhakrishnan wrote:
> On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
> wrote:
>>
>>> On May 16, 2019, at 7:22 PM, Jeff Law wrote:
>>>
>>> On 5/15/19 5:19 AM, Richard Biener wrote:
For the official converted repo do we really want all (old)
development b
On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
wrote:
>
> > On May 16, 2019, at 7:22 PM, Jeff Law wrote:
> >
> > On 5/15/19 5:19 AM, Richard Biener wrote:
> >>
> >> For the official converted repo do we really want all (old)
> >> development branches to be in the
> >> main git repo? I suppose we
> On May 16, 2019, at 7:22 PM, Jeff Law wrote:
>
> On 5/15/19 5:19 AM, Richard Biener wrote:
>>
>> For the official converted repo do we really want all (old)
>> development branches to be in the
>> main git repo? I suppose we could create a readonly git from the
>> state of the whole repositor
On 5/15/19 5:19 AM, Richard Biener wrote:
>
> For the official converted repo do we really want all (old)
> development branches to be in the
> main git repo? I suppose we could create a readonly git from the
> state of the whole repository
> at the point of conversion (and also keep the SVN in r
> On May 16, 2019, at 3:33 AM, Paul Koning wrote:
>
>
>
>> On May 15, 2019, at 2:42 PM, Eric Gallager wrote:
>>
>>> ...
>>
>> Wasn't Eric S. Raymond working on his own conversion of the GCC repo
>> from SVN to Git? Whatever happened to his?
>
> Yes, and from what I recall he found that doin
> On May 15, 2019, at 9:47 PM, Segher Boessenkool
> wrote:
>
> On Wed, May 15, 2019 at 11:34:34AM +0300, Maxim Kuvyrkov wrote:
>>> On May 15, 2019, at 12:20 AM, Segher Boessenkool
>>> wrote:
>>> On Tue, May 14, 2019 at 07:11:18PM +0300, Maxim Kuvyrkov wrote:
This patch adds scripts to con
> On May 15, 2019, at 2:42 PM, Eric Gallager wrote:
>
>> ...
>
> Wasn't Eric S. Raymond working on his own conversion of the GCC repo
> from SVN to Git? Whatever happened to his?
Yes, and from what I recall he found that doing it fully correctly is an
extremely hard task. It might be a goo
On Wed, May 15, 2019 at 11:34:34AM +0300, Maxim Kuvyrkov wrote:
> > On May 15, 2019, at 12:20 AM, Segher Boessenkool
> > wrote:
> > On Tue, May 14, 2019 at 07:11:18PM +0300, Maxim Kuvyrkov wrote:
> >> This patch adds scripts to contrib/ to migrate full history of GCC's
> >> subversion repository
On 5/15/19, Maxim Kuvyrkov wrote:
>> On May 15, 2019, at 2:19 PM, Richard Biener
>> wrote:
>>
>> On Tue, May 14, 2019 at 6:11 PM Maxim Kuvyrkov
>> wrote:
>>>
>>> This patch adds scripts to contrib/ to migrate full history of GCC's
>>> subversion repository to git. My hope is that these scripts
> On May 15, 2019, at 2:19 PM, Richard Biener
> wrote:
>
> On Tue, May 14, 2019 at 6:11 PM Maxim Kuvyrkov
> wrote:
>>
>> This patch adds scripts to contrib/ to migrate full history of GCC's
>> subversion repository to git. My hope is that these scripts will finally
>> allow GCC project to m
On Tue, May 14, 2019 at 6:11 PM Maxim Kuvyrkov
wrote:
>
> This patch adds scripts to contrib/ to migrate full history of GCC's
> subversion repository to git. My hope is that these scripts will finally
> allow GCC project to migrate to Git.
>
> The result of the conversion is at
> https://gith
> On May 15, 2019, at 12:20 AM, Segher Boessenkool
> wrote:
>
> On Tue, May 14, 2019 at 07:11:18PM +0300, Maxim Kuvyrkov wrote:
>> This patch adds scripts to contrib/ to migrate full history of GCC's
>> subversion repository to git. My hope is that these scripts will
>> finally allow GCC projec
1 - 100 of 102 matches
Mail list logo
