On Thu, 9 Jan 2020, Joseph Myers wrote:
> Here's a test conversion with the conversion machinery in what should be
> essentially final form. This is like the "b" versions (dead and vendor
> branches present but not fetched by default), with the addition of refs
> from the existing git mirror
On Fri, 3 Jan 2020, Joseph Myers wrote:
> On Sat, 28 Dec 2019, Joseph Myers wrote:
>
> > Two more.
> >
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6a.git
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6b.git
>
> Two more.
>
>
Richard,
Thanks for the offer, but no need. Just wanted to confirm with some
detail that I reviewed aspects of the svn-git conversion and LGTM.
BTW, I too saw the issue (in 14 out of 261 master commits) reported by
Andrew where (in my case) "ljrit...@gcc.gnu.org" was used in Author
line(s)
On 06/01/2020 22:09, Loren James Rittle wrote:
On Fri, 3 Jan 2020, Joseph Myers wrote:
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7a.git
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7b.git
I have not had a substantial commit to gcc [or, likely, post to this
list] in a decade
On 06/01/2020 23:57, Andrew Pinski wrote:
> On Fri, Jan 3, 2020 at 4:38 AM Joseph Myers wrote:
>>
>> On Sat, 28 Dec 2019, Joseph Myers wrote:
>>
>>> Two more.
>>>
>>> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6a.git
>>> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6b.git
>>
>>
On Mon, 6 Jan 2020, Andrew Pinski wrote:
> ** Also I Noticed the author for that revision is detected as
> pins...@gcc.gnu.org but that is because I used different cases for the
> emails in the changelog.
In my review of possibly suspect authors I'm concentrating on cases where
the author name
On Fri, Jan 3, 2020 at 4:38 AM Joseph Myers wrote:
>
> On Sat, 28 Dec 2019, Joseph Myers wrote:
>
> > Two more.
> >
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6a.git
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6b.git
>
> Two more.
>
>
On Fri, 3 Jan 2020, Joseph Myers wrote:
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7a.git
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7b.git
I have not had a substantial commit to gcc [or, likely, post to this
list] in a decade THUS a warm howdy to anyone still around from
On Sat, 28 Dec 2019, Joseph Myers wrote:
> Two more.
>
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6a.git
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6b.git
Two more.
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7a.git
On Sun, 22 Dec 2019, Joseph Myers wrote:
> Two more.
>
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-5a.git
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-5b.git
Two more.
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6a.git
Andreas Schwab :
> On Dez 25 2019, Eric S. Raymond wrote:
>
> > That's easily fixed by adding a timezone entry to your author-map
> > entry - CET, is it?
>
> The time zone is not constant.
Congratulations, you have broken one of reposurgeon's assumptions.
It is possible to use reposurgeon;d
On Fri, 27 Dec 2019, Andreas Schwab wrote:
> SVN also only has a committer, so the fabricated author should not be
> influenced by the committer.
That issue has been fixed.
--
Joseph S. Myers
j...@polyomino.org.uk
On Dez 25 2019, Eric S. Raymond wrote:
> That's easily fixed by adding a timezone entry to your author-map
> entry - CET, is it?
The time zone is not constant.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now
On Dez 25 2019, Joseph Myers wrote:
> On investigation, I think you are referring to the conversion of r269472.
> That was committed for you by Jim Wilson and thus has you as author and
> Jim Wilson as committer and Jim Wilson's timezone entry has been applied.
> So the argument here is that
On Thu, Dec 26, 2019 at 05:32:52PM -0500, Eric S. Raymond wrote:
> Toon Moene :
> > So we are going to base this world wide free software endeavor on a source
> > code system that doesn't keep time by UTC ?
>
> They all *do* keep time by UTC.
(Git stores unix time, instead -- close enough ;-) )
On 25/12/2019 11:02, Roman Zhuykov wrote:
> First of all thanks to everyone who spent time making the conversion
> better and better. Here is my 2c, I have studied a little my colleagues
> trunk history in Maxim's gcc-pretty vs gcc-reposurgeon-5b.
>
> 1) In gcc-pretty timezone info is lost in
Vincent Lefevre :
> What matters is that the date is correct. I don't think the timezone
> matters (that's why SVN doesn't store timezone information, I assume),
> possibly except for the committer himself (?). For instance,
Subversion doesn't store timezone because all commits are consifered
to
On 2019-12-26 16:30:15 -0500, Eric S. Raymond wrote:
> Vincent Lefevre :
> > > Here's why you want to get timezones right: there are going to be times
> > > when the order of commits is significant information for a developer's
> > > understanding of what happened. But without a timezone you only
Toon Moene :
> On 12/26/19 10:30 PM, Eric S. Raymond wrote:
>
> > Me, I don't undertstand why version-control systems designed for distributed
> > use don't ignore timezones entirely and display all times in UTC - relative
> > time is surely more imoortant than the commit time's relationship to
On 12/26/19 10:30 PM, Eric S. Raymond wrote:
Me, I don't undertstand why version-control systems designed for distributed
use don't ignore timezones entirely and display all times in UTC - relative
time is surely more imoortant than the commit time's relationship to solar
noon wherever the
Vincent Lefevre :
> > Here's why you want to get timezones right: there are going to be times
> > when the order of commits is significant information for a developer's
> > understanding of what happened. But without a timezone you only know
> > the actual time of a commit to 24-hour resoltion.
On 2019-12-25 14:33:45 -0500, Eric S. Raymond wrote:
> Segher Boessenkool :
> > The goal is not to pretend we never used SVN.
>
> One of *my* goals is that the illusion of git back to the beginning of
> time should be as consistent as possible.
>
> > The goal is to have a Git repo that is as
Joseph Myers :
> On Wed, 25 Dec 2019, Andreas Schwab wrote:
>
> > On Dez 25 2019, Joseph Myers wrote:
> >
> > > Timezones for any email address can be specified in gcc.map for any
> > > authors wishing to have an appropriate timezone used for their commits.
> >
> > But that should not be used
Segher Boessenkool :
> The goal is not to pretend we never used SVN.
One of *my* goals is that the illusion of git back to the beginning of
time should be as consistent as possible.
> The goal is to have a Git repo that is as useful as possible for us.
Exactly. I've already written about
Andreas Schwab :
> Definitely not. I have never authored or committed any revision in the
> -0800 time zone.
That's easily fixed by adding a timezone entry to your author-map
entry - CET, is it? That will prevent reposurgeon from making any
attempt to deduce your timezone.
It would be
On Wed, Dec 25, 2019 at 03:36:38PM +, Joseph Myers wrote:
> On Wed, 25 Dec 2019, Andreas Schwab wrote:
>
> > On Dez 25 2019, Joseph Myers wrote:
> >
> > > Timezones for any email address can be specified in gcc.map for any
> > > authors wishing to have an appropriate timezone used for their
On Wed, 25 Dec 2019, Andreas Schwab wrote:
> On Dez 25 2019, Joseph Myers wrote:
>
> > Timezones for any email address can be specified in gcc.map for any
> > authors wishing to have an appropriate timezone used for their commits.
>
> But that should not be used for unrelated authors.
It's
On Dez 25 2019, Joseph Myers wrote:
> Timezones for any email address can be specified in gcc.map for any
> authors wishing to have an appropriate timezone used for their commits.
But that should not be used for unrelated authors.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key
On Wed, 25 Dec 2019, Andreas Schwab wrote:
> > Not sure we need that info, but reposurgeon is more correct here.
>
> Definitely not. I have never authored or committed any revision in the
> -0800 time zone.
If reposurgeon is defaulting to the local time where the conversion is
run, there's a
On Dez 25 2019, Roman Zhuykov wrote:
> 1) In gcc-pretty timezone info is lost in both author/commiter date
> (keeping UTC time correct, certainly).
Since svn doesn't record time zones you cannot lose them, only fabricate
them.
> Not sure we need that info, but reposurgeon is more correct here.
Joseph Myers :
> These are all cases covered by the request-for-enhancement issue for
> adding Co-Authored-by: when the ChangeLog header names multiple authors,
> as the corresponding de facto git idiom for that case.
I apologize, but I am growing doubtful I can deliver that. Even if I
can, it
On Wed, 25 Dec 2019, Roman Zhuykov wrote:
> 2) Some thoughts about script for summarizing commit log messages:
> 2a) Why r143753 and r150680 not have "re PR..." summary instead of "[multiple
> changes]" ?
> 2b) On the contrary r155892 have to mention two PRs, even "[multiple changes]"
> is better
First of all thanks to everyone who spent time making the conversion
better and better. Here is my 2c, I have studied a little my colleagues
trunk history in Maxim's gcc-pretty vs gcc-reposurgeon-5b.
1) In gcc-pretty timezone info is lost in both author/commiter date
(keeping UTC time
On Tue, Dec 24, 2019 at 05:16:54PM +, Joseph Myers wrote:
> On Tue, 24 Dec 2019, Segher Boessenkool wrote:
> > > That's because that commit also edits ChangeLog entries from other
> > > authors. When a commit adds / edits ChangeLog entries for more than one
> > > author (the difference
On Tue, 24 Dec 2019, Segher Boessenkool wrote:
> > That's because that commit also edits ChangeLog entries from other
> > authors. When a commit adds / edits ChangeLog entries for more than one
> > author (the difference between purely editing an existing entry and adding
> > a new one,
On Tue, Dec 24, 2019 at 11:50:30AM +, Joseph Myers wrote:
> On Mon, 23 Dec 2019, Roman Zhuykov wrote:
> > I've never used zhr...@gcc.gnu.org email in ChangeLog files. So, it seems
> > odd
> > that it is used in r270511 (my first commit as maintainer), but not in next
>
> That's because that
On Mon, 23 Dec 2019, Roman Zhuykov wrote:
> I've never used zhr...@gcc.gnu.org email in ChangeLog files. So, it seems odd
> that it is used in r270511 (my first commit as maintainer), but not in next
That's because that commit also edits ChangeLog entries from other
authors. When a commit adds
> On Dec 22, 2019, at 4:56 PM, Joseph Myers wrote:
>
> On Thu, 19 Dec 2019, Joseph Myers wrote:
>
>> And two more.
>>
>> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-4a.git
>> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-4b.git
>
> Two more.
>
>
22.12.2019 16:56, Joseph Myers wrote:
On Thu, 19 Dec 2019, Joseph Myers wrote:
And two more.
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-4a.git
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-4b.git
Two more.
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-5a.git
On Thu, 19 Dec 2019, Joseph Myers wrote:
> And two more.
>
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-4a.git
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-4b.git
Two more.
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-5a.git
On Wed, 18 Dec 2019, Joseph Myers wrote:
> There are now four more repositories available.
>
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-2a.git
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-2b.git
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git
>
On Thu, 19 Dec 2019, Jason Merrill wrote:
> So a 30% space savings; that's pretty significant. Though I wonder how
> much of that is refs/dead and refs/deleted, which seem unnecessary to carry
> over to git at all. I wonder if it would make sense to put them in a
> separate repository that
On Wed, Dec 18, 2019 at 1:17 PM Joseph Myers
wrote:
> On Wed, 18 Dec 2019, Jason Merrill wrote:
>
> > On Tue, Dec 17, 2019 at 4:39 PM Joseph Myers
> > wrote:
> >
> > > Points for consideration:
> > >
> > > 1. Do we want some kind of rearrangement of refs as in the 1b
> > > repository or not?
>
On Thu, 19 Dec 2019, Bernd Schmidt wrote:
> On 12/18/19 10:55 PM, Joseph Myers wrote:
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git
>
> I cloned this one and started trying random things again.
> The previous one had some strange-looking merge commits, but it sounded like
> that
On 12/18/19 10:55 PM, Joseph Myers wrote:
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git
I cloned this one and started trying random things again.
The previous one had some strange-looking merge commits, but it sounded
like that was a known issue, and indeed the ones I had seen
On Tue, 17 Dec 2019, Joseph Myers wrote:
> I've made test conversions of the GCC repository with reposurgeon
> available (gcc.gnu.org / sourceware.org account required to access
> these git+ssh repositories, it doesn't need to be one in the gcc group
> or to have shell access). More information
On Wed, 18 Dec 2019, Jason Merrill wrote:
> On Tue, Dec 17, 2019 at 4:39 PM Joseph Myers
> wrote:
>
> > Points for consideration:
> >
> > 1. Do we want some kind of rearrangement of refs as in the 1b
> > repository or not?
> >
>
> Maybe? How much space does that save in a clone? How much
On Wed, 18 Dec 2019, Joseph Myers wrote:
> On Wed, 18 Dec 2019, Joseph Myers wrote:
>
> > On Wed, 18 Dec 2019, Bernd Schmidt wrote:
> >
> > > On 12/17/19 10:32 PM, Joseph Myers wrote:
> > > > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git
> > >
> > > It seems that permission bits
On Tue, Dec 17, 2019 at 4:39 PM Joseph Myers
wrote:
> Points for consideration:
>
> 1. Do we want some kind of rearrangement of refs as in the 1b
> repository or not?
>
Maybe? How much space does that save in a clone? How much work does a
partial clone add on the server, since the server
On Wed, 18 Dec 2019, Joseph Myers wrote:
> On Wed, 18 Dec 2019, Bernd Schmidt wrote:
>
> > On 12/17/19 10:32 PM, Joseph Myers wrote:
> > > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git
> >
> > It seems that permission bits are not reproduced entirely correctly. For
> > example,
On Wed, 18 Dec 2019, Bernd Schmidt wrote:
> On 12/17/19 10:32 PM, Joseph Myers wrote:
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git
>
> It seems that permission bits are not reproduced entirely correctly. For
> example, contrib/check_GNU_style_lib.py went from -rwxr-xr-x in svn
Bernd Schmidt :
> I vote for including .cvsignore files. Their absence makes diff comparisons
> of "git ls-tree" on specific revisions needlessly noisy.
A few minutes ago I implmemted and pushed a --cvsignores read option
for Subversion dumps. That should do what you eant.
--
On 12/17/19 10:32 PM, Joseph Myers wrote:
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git
It seems that permission bits are not reproduced entirely correctly. For
example, contrib/check_GNU_style_lib.py went from -rwxr-xr-x in svn (and
the git-svn repository) to -rw-r--r-- in this
I've made test conversions of the GCC repository with reposurgeon
available (gcc.gnu.org / sourceware.org account required to access
these git+ssh repositories, it doesn't need to be one in the gcc group
or to have shell access). More information about the repositories,
conversion choices made
54 matches
Mail list logo
