Re: Proposal for the transition timetable for the move to GIT

On Mon, 16 Dec 2019, Segher Boessenkool wrote: > On Mon, Dec 16, 2019 at 01:43:48PM +0100, Mark Wielaard wrote: > > On Mon, 2019-12-16 at 11:29 +0000, Joseph Myers wrote: > > > On Mon, 16 Dec 2019, Mark Wielaard wrote: > > > > > > > Should we go with the gc

Re: Proposal for the transition timetable for the move to GIT

On Mon, 16 Dec 2019, Segher Boessenkool wrote: > Most of us are perfectly happy even with the current git mirror, for > old commits. We want "real" git to make the workflow for new commits > better. > > No more delays, _please_. The timetable is a useful guideline. It should not be our master

Re: Proposal for the transition timetable for the move to GIT

On Mon, 16 Dec 2019, Mark Wielaard wrote: > On Mon, 2019-12-16 at 13:56 +0000, Joseph Myers wrote: > > classpath-generics gcj/classpath-095-import-branch > > libstdcxx_so_7-2-branch st/binutils st/mono-based-binutils. > > The classpath "branches" should not

Re: Proposal for the transition timetable for the move to GIT

On Mon, 16 Dec 2019, Segher Boessenkool wrote: > And the current mirror is "right", already, as Jeff said at the Cauldron > (a minute before we unanymously decided to do the conversion soon; this > is over three months ago already). All the discussion at the Cauldron tells us is many people like

Re: Proposal for the transition timetable for the move to GIT

On Mon, 16 Dec 2019, Jeff Law wrote: > On Mon, 2019-12-16 at 11:29 +0000, Joseph Myers wrote: > > On Mon, 16 Dec 2019, Mark Wielaard wrote: > > > > > Should we go with the gcc-reparent.git repo now? > > > > I think we should go with the reposu

Re: Proposal for the transition timetable for the move to GIT

On Mon, 16 Dec 2019, Segher Boessenkool wrote: > Hi, > > On Mon, Dec 16, 2019 at 05:07:48PM +0000, Joseph Myers wrote: > > Yes. It should be possible to confirm branch tip conversions and other > > properties of the repository (e.g. that all branch tips are properly &

Re: Proposal for the transition timetable for the move to GIT

On Mon, 16 Dec 2019, Segher Boessenkool wrote: > We talked about it for days, and as far as I understand it Richard agreed. > > But, there is no way I can verify this yet, or is there? Is there a repo > we can look at? Something close to final. The conversion run I started this afternoon is no

Test GCC conversion with reposurgeon available

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 and

Re: Test GCC conversion with reposurgeon available

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

Re: Test GCC conversion with reposurgeon available

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 en

Re: Test GCC conversion with reposurgeon available

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 >

Re: Test GCC conversion with reposurgeon available

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 mu

Re: Proposal for the transition timetable for the move to GIT

On Wed, 18 Dec 2019, Jeff Law wrote: > > That isn't what I said. I said that freshly constructed complex software > > will have more and deeper errors than stupid simple scripts do (or I > > implied that at least, maybe it wasn't clear). And I only say this > > because the opposite was claimed,

Re: Test GCC conversion with reposurgeon available

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 acce

Re: Commit messages and the move to git

On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote: > I've attached a sample from the start of the fixed list - the full list is far > too big to post to give a flavour of how the script currently works. Note > that annotations of the form [checkme: ] in the summary are for diagnostic > purp

Re: Commit messages and the move to git

On Wed, 18 Dec 2019, Joseph Myers wrote: > On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote: > > > I've attached a sample from the start of the fixed list - the full list is > > far > > too big to post to give a flavour of how the script currently works. Not

Re: Test GCC conversion with reposurgeon available

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 s

Re: Unix philosopy vs. poor semantic locality

On Wed, 18 Dec 2019, Eric S. Raymond wrote: > And that, ladies and gentlemen, is why reposurgeon has to be as > large and complex as it is. And, in the end, it *is* complex software on which you build simple scripts. gcc.lift is a simple script, written in the domain-specific reposurgeon langu

Re: Commit messages and the move to git

On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote: > Best of all would be a pull request on > https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py directly. Note if doing that, it helps to check "Allow commits from members who can merge to the target branch." when creating the

Re: Test GCC conversions (publicly) available

On Thu, 19 Dec 2019, Eric S. Raymond wrote: > There are other problems that might cause a delay beyond the > 31st, however. Best if I let Joseph nd Richard explain those. I presume that's referring to the checkme: bug annotations where the PR numbers in commit messages seem suspicious. I don't

Re: Commit messages and the move to git

On Thu, 19 Dec 2019, Jonathan Wakely wrote: > These scraped "INVALID" as the component from the changelog, because > it said "libgfortran/24685": "INVALID" means the PR was closed as INVALID rather than FIXED, which makes it suspect for a commit to claim to be fixing it. (Though since those ar

Re: Commit messages and the move to git

On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote: > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes > > (most of?) the most egregious ones, like fortran fixes with c++ PR > > numbers and vice versa. Jakub and I have several whitelist commits > > too, but I think they're al

Re: Test GCC conversion with reposurgeon available

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 refer

Re: Commit messages and the move to git

On Thu, 19 Dec 2019, Jonathan Wakely wrote: > It might be reasonable to assume rtl-optimization and > tree-optimization are aliases, and not treat it as suspicious if those > two appear mixed up. And anything where bugzilla has component debug > or lto and the commit is tree-optimization is probab

Re: Test GCC conversion with reposurgeon available

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-3

Re: Commit messages and the move to git

On Thu, 19 Dec 2019, Jonathan Wakely wrote: > On Thu, 19 Dec 2019 at 15:49, Joseph Myers wrote: > > > > On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote: > > > > > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes > > > > (mo

Re: Commit messages and the move to git

On Thu, 19 Dec 2019, Jonathan Wakely wrote: > Jakub and I came up with the following list of suggestions for > component changes: Since we don't normally review changes to individual bugs, if you think the new component is better than the old one (is a better representation of the subject area

Re: Commit messages and the move to git

On Thu, 19 Dec 2019, Jonathan Wakely wrote: > I've attached an updated list to this mail, which removes the items > we've analysed. There are 531 remaining. With the current version of the script (including the various whitelisted component pairs discussed) and with data freshly downloaded from

Re: Commit messages and the move to git

On Fri, 20 Dec 2019, Jonathan Wakely wrote: > On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote: > > > > On Thu, 19 Dec 2019, Jonathan Wakely wrote: > > > > > I've attached an updated list to this mail, which removes the items > > > we've an

Re: Commit messages and the move to git

On Fri, 20 Dec 2019, Jonathan Wakely wrote: > I've sent another pull request fixing another 20. Here is the list > with those 20 removed (and this still includes the libcpp vs > preprocessor ones that will be handled by the new alias). Thanks, merged. -- Joseph S. Myers jos...@codesourcery.com

Re: Commit messages and the move to git

On Fri, 20 Dec 2019, Jonathan Wakely wrote: > On Fri, 20 Dec 2019 at 22:58, Joseph Myers wrote: > > > > On Fri, 20 Dec 2019, Jonathan Wakely wrote: > > > > > I've sent another pull request fixing another 20. Here is the list > > > with those 20 re

Re: Test GCC conversion with reposurgeon available

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 git+ssh://gcc.gnu.org/home/

Re: Test GCC conversion with reposurgeon available

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

Re: Test GCC conversion with reposurgeon available

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, possib

Re: Test GCC conversion with reposurgeon available

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

Re: Proposal for the transition timetable for the move to GIT

On Wed, 25 Dec 2019, Segher Boessenkool wrote: > git-svn did not miss any branches. Finding branches is not done by > git-svn at all, for this. These branches were skipped because they > have nothing to do with GCC, have no history in common (they are not > descendants of revision 1). They can

Re: Proposal for the transition timetable for the move to GIT

On Wed, 25 Dec 2019, Segher Boessenkool wrote: > On Wed, Dec 25, 2019 at 07:07:47AM -0500, Eric S. Raymond wrote: > > For each of these exceptional commits a converter to Git has a choice > > of dropping the commit, turning it into some sort of annotated tag, or > > leaving it in place as a zero-o

Re: Test GCC conversion with reposurgeon available

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 s

Re: Test GCC conversion with reposurgeon available

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

Re: Proposal for the transition timetable for the move to GIT

On Thu, 26 Dec 2019, Alexandre Oliva wrote: > Could make it a requirement that at least the commits associated with > head branches and published tags compare equal in both conversions, or > that differences are known, understood and accepted, before we switch > over to either one? Going over all

Re: Proposal for the transition timetable for the move to GIT

On Thu, 26 Dec 2019, Jakub Jelinek wrote: > Is there some easy way (e.g. file in the conversion scripts) to correct > spelling and other mistakes in the commit authors? These can be corrected via reposurgeon commands in gcc.lift (see the existing "// attribution =A set jwakely@gmail.com" co

Re: Proposal for the transition timetable for the move to GIT

On Thu, 26 Dec 2019, Maxim Kuvyrkov wrote: > Reposurgeon creates merge entries on trunk when changes from a branch > are merged into trunk. This brings entire development history from the > branch to trunk, which is both good and bad. The good part is that we > get more visibility into how th

Re: Proposal for the transition timetable for the move to GIT

On Thu, 26 Dec 2019, Jakub Jelinek wrote: > On Thu, Dec 26, 2019 at 04:58:22PM +0000, Joseph Myers wrote: > > If we don't want merge commits on git master for the cases where people > > put merge properties on trunk in the past, we can use a reposurgeon > > "unmer

Re: Proposal for the transition timetable for the move to GIT

On Thu, 26 Dec 2019, Alexandre Oliva wrote: > I don't see that it does (help). Incremental conversion of a missed > branch should include the very same parent links that the conversion of > the entire repo would, just linking to the proper commits in the adopted > conversion. git-svn can do that

Re: Proposal for the transition timetable for the move to GIT

On Thu, 26 Dec 2019, Jakub Jelinek wrote: > Is there some easy way (e.g. file in the conversion scripts) to correct > spelling and other mistakes in the commit authors? I've added author fixups to bugdb.py, so you can add any number of fixes (e.g. based on authors that look suspicious in "git sh

Re: Proposal for the transition timetable for the move to GIT

On Thu, 26 Dec 2019, Joseph Myers wrote: > > It appears that .gitignore has been added in r1 by reposurgeon and then > > deleted at r130805. In SVN repository .gitignore was added in r195087. > > I speculate that addition of .gitignore at r1 is expected, but it's >

Re: Proposal for the transition timetable for the move to GIT

On Fri, 27 Dec 2019, Richard Earnshaw (lists) wrote: > I'm not really sure I understand why we don't want merge commits into > trunk, especially for large changes. Performing archaeology on a change > is just so much easier if the development history is just there. To some extent it fits with th

Re: Proposal for the transition timetable for the move to GIT

On Fri, 27 Dec 2019, Alexandre Oliva wrote: > That depends on the used tool. A reproducible one, or at least one that > aimed at stability across multiple conversions, could make this easier, > but I guess reposurgeon is not such a tool. Which suggests to me we > have to be even more reassured o

Re: What's the plan for git-only branches?

On Fri, 27 Dec 2019, David Malcolm wrote: > What the plan for such branches? My view is: add all refs (and thus all objects) from the existing git mirror to the converted repository, probably under names that are not fetched by default (this increases the repository size, after git gc --aggres

Re: What's the plan for git-only branches?

On Fri, 27 Dec 2019, Richard Biener wrote: > Does this allow to keep the URL of the old git mirror and the new > official fit repo the same or would that cause conflicts with existing > clones? The URL of the old mirror feels like it's the right URL to use for the new conversion. It would cau

Re: Test GCC conversion with reposurgeon available

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

Re: Proposal for the transition timetable for the move to GIT

On Fri, 27 Dec 2019, Eric S. Raymond wrote: > > Merge info is not one of those cases. > > Sometimes. Some Subversion mergeinfo operations map to Git's > branch-centric merging. Many do not, corresponding to cherry-picks > that cannot be expressed in a Git history. And in the case of merge commi

Re: Git conversion: fixing email addresses from ChangeLog files

On Sat, 28 Dec 2019, Segher Boessenkool wrote: > On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote: > > 1 Author: Segher Boessenkool > > *730 Author: Segher Boessenkool > > 2 Author: Segher Boesssenkool > > The first and third are only in changelogs. The

Re: Test GCC conversion with reposurgeon available

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 git+ssh://gcc.gnu.org/home/

Re: Git conversion: fixing email addresses from ChangeLog files

On Sat, 28 Dec 2019, Segher Boessenkool wrote: > > This is about extracting attributions from changelogs when unambiguous > > there, and then correcting mistakes or otherwise making minor variants > > more uniform. > > Yes, and I'm saying you probably shouldn't do that. Extracting attributions

Re: Git conversion: fixing email addresses from ChangeLog files

On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote: > My suggestion would be that we try to canonicalize all the author > entries to UTF-8 as that avoids the limitations of ISO-8859-1, but that > would probably need further fixups to detect the additional names that > need rewriting. What I've i

Re: Git conversion: fixing email addresses from ChangeLog files

On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote: > I've added the list of emails that I posted yesterday to the conversion > scripts. I've not written anything to reprocess that yet. I want to > leave that until we've completed the general review of the preferred > changes we want. Auto-gen

Re: Git conversion: fixing email addresses from ChangeLog files

On Sat, 28 Dec 2019, Joseph Myers wrote: > On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote: > > > I've added the list of emails that I posted yesterday to the conversion > > scripts. I've not written anything to reprocess that yet. I want to > > leave that

Re: Git conversion: fixing email addresses from ChangeLog files

On Sat, 28 Dec 2019, Joseph Myers wrote: > Concretely, what I'd suggest is: convert ISO-8859-1 entries in the > checked-in list to UTF-8, removing anything that thereby becomes a > duplicate or unnecessary; handle anything whose encoding isn't simply > ISO-8859-1 or UTF-8

Re: Proposal for the transition timetable for the move to GIT

On Sun, 29 Dec 2019, Maxim Kuvyrkov wrote: > With the "Missed merges" problem (see below) I don't see how reposurgeon > conversion can be considered "ready". It aims to be conservatively safe regarding merges, erring on the side of not adding incorrect merges if in doubt. Because of the diffic

Re: The far past of GCC

On Sat, 28 Dec 2019, Jeff Law wrote: > I believe RCS was initially used circa 1992 on the FSF machine which > held the canonical GCC sources. But I'm not aware of anyone still > having a copy of the old RCS ,v files. See ftp://gcc.gnu.org/pub/gcc/old-releases/old-cvs/ for the old repository (th

Re: Proposal for the transition timetable for the move to GIT

On Sun, 29 Dec 2019, Mark Wielaard wrote: > Maybe we should have a separate historical git repo which contains > everything that we were able to salvage and that people could git > remote add if they are really, really interested. I'm not convinced that's very different from having one repo with

Re: Git conversion: fixing email addresses from ChangeLog files

On Sun, 29 Dec 2019, Joseph Myers wrote: > I've now made those changes to the checked-in list so it's pure UTF-8, and > thus easier to review and edit. We still need to implement code in > bugdb.py to use that list to pick the preferred form from each list of > variant

Re: Proposal for the transition timetable for the move to GIT

On Sun, 29 Dec 2019, Eric S. Raymond wrote: > Joseph Myers : > > The case you mention is one where there was a merge to a branch not from > > its immediate parent but from an indirect parent. I don't think it would > > be hard to support detecting such merges in repos

Re: Proposal for the transition timetable for the move to GIT

On Sun, 29 Dec 2019, Richard Earnshaw (lists) wrote: > gcc-reparent is better, but many (most?) of the release tags are shown > as merge commits with a fake parent back to the gcc-3 branch point, > which is certainly not what happened when the tagging was done at that > time. And looking at the h

Re: Proposal for the transition timetable for the move to GIT

On Mon, 30 Dec 2019, Segher Boessenkool wrote: > To make it not be super much work, I'd do the second option: better > heuristics. Those in Maxim's conversion have been great since over half > a year, you could borrow some, or peek for inspiration? Actually, comparing authors between the two con

Re: Proposal for the transition timetable for the move to GIT

On Mon, 16 Dec 2019, Jeff Law wrote: > > Joseph Myers has made his choice. He has said repeatedly that he > > wants to follow through with the reposurgeon conversion, and he's > > putting his effort behind that by writing tests and even contributing > > code to re

Re: Test GCC conversion with reposurgeon available

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 git+ssh://gcc.gnu.org/home/

Re: Test GCC conversion with reposurgeon available

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 n

Re: Proposal for the transition timetable for the move to GIT

On Wed, 8 Jan 2020, Eric S. Raymond wrote: > They use your feedback to find places where their comment-processing > scripts could be improved; we've used it learn what additional > oddities in ChangeLogs we need to be able to handle automatically. I've used comparisons of authors in the two conve

Re: Test GCC conversion with reposurgeon available

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. > &g

Re: Proposal for the transition timetable for the move to GIT

On Wed, 8 Jan 2020, Jeff Law wrote: > Is there any chance we could get one more trunk snapshot before the > conversion starts -- even if that means firing up the snapshot process > Friday? It'd be quite useful for the ongoing Fedora build testing. I could run a snapshot manually. I was planning

Re: GIT conversion: question about tags & release branches

On Thu, 9 Jan 2020, Martin Liška wrote: > On 1/9/20 12:45 PM, Martin Jambor wrote: > > I use the release tags every now and then so this caught my attention > > but I do not understand what the problem is? > > Problem is that if you do: > $ git log origin/releases/gcc-9 > > you will not find the

Re: Rescue of prehistoric GCC versions

On Thu, 9 Jan 2020, Eric S. Raymond wrote: > If anyone else can scrounge up materials that could help complete > the fossil sequence, now would be a really good time for that. We > have only three days at most left to integrate them. I want to consider the conversion machinery essentially frozen

Re: GCC Git hooks

On Mon, 16 Sep 2019, Joel Brobecker wrote: > Looking at the configuration file, I believe the git-hooks > should have most, if not all, of the features that would be needed for > the GCC repository. In particular, there is already a way to relay > commits to third-party tools via calling of a scri

Re: Test GCC conversion with reposurgeon available

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 > f

Re: GCC Git hooks

On Thu, 9 Jan 2020, Joseph Myers wrote: > On Mon, 16 Sep 2019, Joel Brobecker wrote: > > > Looking at the configuration file, I believe the git-hooks > > should have most, if not all, of the features that would be needed for > > the GCC repository. In particular, there i

Re: GCC Git hooks

On Fri, 10 Jan 2020, Jonathan Wakely wrote: > Could you avoid the double negative here? And the error message could > be more specific to the actual error by testing the two cases > separately, e.g. I'm sort of hoping we don't end up using the hooks in this form for very long - the patch was pos

Re: Proposal for the transition timetable for the move to GIT

On Fri, 10 Jan 2020, Iain Sandoe wrote: > One minor nit (and accepted that this might be too late). Hooks can always be changed after the conversion is live. > mail commit messages like this: > [gcc-reposurgeon-8(refs/users/jsm28/heads/test-branch)] Test git hooks > interaction with Bugzilla. >

Re: Proposal for the transition timetable for the move to GIT

On Fri, 10 Jan 2020, Maxim Kuvyrkov wrote: > To me this looks like cherry-picks of r182541 and r182547 from > redhat/gcc-4_7-branch into redhat/gcc-4_8-branch. r182541 is the first commit on /branches/redhat/gcc-4_7-branch after it was created as a copy of trunk. I.e., merging and cherry-picki

Re: Proposal for the transition timetable for the move to GIT

On Thu, 9 Jan 2020, Joseph Myers wrote: > On Wed, 8 Jan 2020, Jeff Law wrote: > > > Is there any chance we could get one more trunk snapshot before the > > conversion starts -- even if that means firing up the snapshot process > > Friday? It'd be quite useful

Re: GCC Git hooks

On Thu, 9 Jan 2020, Joseph Myers wrote: > Concretely, these are the changes I'm currently using to configure the > hooks in a way I think appropriate for GCC, and it would be useful if the > hooks could support such configuration in a more generic way in future so > that we

Re: GIT: Monotonically increasing trunk and release branch ids

On Fri, 10 Jan 2020, Jakub Jelinek wrote: > We would need to add some tags (I wouldn't bother with pre-GCC 5 era, > because that doesn't have single number version numbers in the branch > names), like: > for r in 10 9 8 7 6; do > git tag branchpoints/gcc-$r `git rev-list $(git merge-base origin/

Re: GIT: Monotonically increasing trunk and release branch ids

On Fri, 10 Jan 2020, Jakub Jelinek wrote: > > Those look like the start of GCC version N development (just after the > > branchpoint for N-1), not the branchpoint as commonly understood; naming > > them "branchpoints" seems confusing. > > Ok, so what about basepoints instead? That seems a bett

Re: GCC Git hooks

On Fri, 10 Jan 2020, Joel Brobecker wrote: > > Plus one further change now: if a newly created branch is in refs/heads/, > > require it to be in refs/heads/devel/ or refs/heads/releases/ (i.e. > > enforce a particular branch naming convention, in particular to prevent > > mistakes where people

Re: GCC Git hooks

On Fri, 10 Jan 2020, Joel Brobecker wrote: > > No. What we want to ensure is that people don't accidentally create a > > branch called refs/heads/foo when they should (by our naming conventions) > > have created one called refs/heads/devel/foo or > > refs/users/someone/heads/foo. Our naming c

Re: GCC Git hooks

One further change I've made for the GCC hooks: rejecting commits whose commit message's first line looks like a ChangeLog header (matches the regular expression '[0-9]{4}-[0-9]{2}-[0-9]{2} .*<.*@.*>'). That should help avoid people's habits writing such commit messages carrying over into comm

Re: GIT: Monotonically increasing trunk and release branch ids

On Fri, 10 Jan 2020, Jakub Jelinek wrote: > We'll need to tweak maintainer-scripts/gcc_release in any case. I now have a conversion of gcc_release to use git. Once the repository conversion is done I'll test it for snapshot creation (which can be done while the converted repository is still re

git conversion in progress

The GCC SVN repository is now read-only for the move to git, as is the old git-svn mirror; the cron job updating that mirror has been disabled, as have gccadmin's cron jobs updating DATESTAMP, generating snapshots and updating online documentation, until those are updated to work from git. Assu

Re: git conversion in progress

On Sat, 11 Jan 2020, Richard Earnshaw wrote: > On 11/01/2020 01:18, Joseph Myers wrote: > > The GCC SVN repository is now read-only for the move to git, as is the old > > git-svn mirror; the cron job updating that mirror has been disabled, as > > have gccadmin's cr

Re: git conversion in progress

On Sat, 11 Jan 2020, Richard Earnshaw wrote: > On 11/01/2020 14:58, Jakub Jelinek wrote: > > On Sat, Jan 11, 2020 at 02:51:21PM +, Richard Earnshaw wrote: > >> https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/vendors/redhat/heads/gcc-9-branch > >> > >> Works > >> > >> Or for tags s/heads/t

Re: git conversion in progress

On Sat, 11 Jan 2020, Thomas Koenig wrote: > Am 11.01.20 um 15:39 schrieb Joseph Myers: > > This conversion is now in place, read-only for checking purposes. I've > > done all the usual validation, including in particular checking branch > > tips and tags against SVN. &g

Re: git conversion in progress

On Sat, 11 Jan 2020, Thomas Koenig wrote: > Hm... I just hope this is a one-time effect, and isn't an indication > that git uses much more resources, server-side, so the current > infrastructure is not up to the task. Is git that much more > resource hungry than svn? Or is this unrelated? I thin

Re: git conversion in progress

On Sat, 11 Jan 2020, Joseph Myers wrote: > the older test conversions 1 through 7). Some cron jobs may be re-enabled > before then, subject to testing (I have git changes to gcc_release ready, > for example, for testing snapshot generation), but the DATESTAMP updates > won't

Re: git conversion in progress

The repository is now open for commits. Snapshot generation and DATESTAMP updates from cron are now enabled. I intend to work on the scripts to update online documentation, but they aren't done yet. *Please help with updating documentation for using git with GCC*.

Re: GCC Git hooks

One more addition I've made to the hooks: rejecting new commits with a line in the commit message starting 'From-SVN: ', since such commits would confuse the scripts people have to find the git commit corresponding to a given SVN commit, and without such a rejection it would be easy for someone

Re: GCC 7.0.0 Status Report (2017-01-09), Stage 4 to start soon

On Mon, 9 Jan 2017, Jakub Jelinek wrote: > We are behind schedule in the amount of P1-P3 PRs compared e.g. to > GCC 5 or GCC 6, so any help with fixing regressions will be appreciated. Also the release notes gcc-7/changes.html are extremely incomplete and need to be filled out - e.g. they're mis

Re: Help with integrating my test program into dejagnu

A test [istarget x86_64-*-gnu] is wrong; i?86-* -m64 should always be handled exactly the same as x86_64-* -m64. You need to work out which ABIs (-m32, -mx32, -m64) this testing is meaningful for. Then, allow both x86_64- and i?86- targets, together with an appropriate effective-target test ("

Re: IEEE 128-bit floating point support for PowerPC RTEMS

On Tue, 24 Jan 2017, Sebastian Huber wrote: > I noticed some issues for RTEMS in this area. Firstly, RTEMS had no > __powerpc__ builtin define, so some source files were effectively disabled, > e.g. ibm-ldouble.c. With __powerpc__ defined, the ibm-ldouble.c didn't compile > due to: When you're us

Re: Testsuite breakages on Cygwin

On Fri, 10 Mar 2017, Daniel Santos wrote: > 3. Wouldn't it be better to move this logic up into DejaGnu and restrict gcc > to using a black-box interface for modifying the environment? GCC is meant to work with a wide range of different DejaGnu versions. There would be a long gap between adding

<    1   2   3   4   5   6   7   8   >