Re: Commit messages and the move to git
Richard Earnshaw (lists) : > Well a lot of that is a property of the conversion tool. git svn does a > relatively poor job of anything other than straight history (I believe it > just ignores the non-linear information. Yes, svn-git does a *terrible* job on anything other than linear history. That is a major reason I'm busting my hump to get the conversion done. It would be very sad if you guys fell into using that. It does a tolerable job of live gatewaying on simple histories, but read this: http://esr.ibiblio.org/?p=6778 > I don't believe any tool can > recreate information for cherry-picking unless it's recorded in the SVN > meta-data. Eric would be better placed to comment here. You are correct, there is nothing practical that can be done in the absence of svn:mergeinfo and svnmerge-integrated properties. > My own observation is that when the SVN commits have merge meta-data, > reposurgeon will pick this up and create links across to the relevant > branches. It does, however seem to create far more links than a traditional > git merge would do, especially when a sequence of commits are referenced. I > don't know if that's essentially unfixable, or if it's something Eric > intends to work on; but I've seen some cases where there are dozens of links > back to a simple sequence of svn commits and where, I suspect, a single link > back to the most recent of that sequence would be all that's really wanted. First I have heard of this. The intent of the present mergeinfo handing is that it looks for mergeinfo declarations that are topologically equivalent to branch merges (that is, they merge all revisions on a source branch rather than cherry-picking isolated revisions) and rendering those as gitspace merge links. There is no attempt to create links corresponding to Subversion cherry picks, as this does not fit the Git DAG model. I have cases that demonstrate this feature working in my test suite, but they are relatively small and artificial. I would not describe my mergeinfo handling as well-tested compared to the rest of the analyzer, and I can thus easily believe your bug report. What I need to troubleshoot this is a test case that is not trivial but of a manageable size - over a couple hundred commits the volume of diagnostics just overwhelms a Mark One Eyeball. Many of my test cases were trimmed to that size by doing stripping and topological reduction on real repositories; I have a tool for this. Do you have a real repository in mind I can start with? The whole gcc history is too huge, but if you were able to tell me that the bug is exhibited within a few thousand commits of origin and point at where, that I could work with. An issue filed on the reposurgeon tracker would be appreciated. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Commit messages and the move to git
Joseph Myers : > I think the main thing to make sure of in the conversion regarding that > issue is that cherry-picks do *not* turn into merge commits I confirm that this is how it now works. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Commit messages and the move to git
On 19/11/2019 11:24, Eric S. Raymond wrote: Richard Earnshaw (lists) : Well a lot of that is a property of the conversion tool. git svn does a relatively poor job of anything other than straight history (I believe it just ignores the non-linear information. Yes, svn-git does a *terrible* job on anything other than linear history. That is a major reason I'm busting my hump to get the conversion done. It would be very sad if you guys fell into using that. It does a tolerable job of live gatewaying on simple histories, but read this: http://esr.ibiblio.org/?p=6778 I don't believe any tool can recreate information for cherry-picking unless it's recorded in the SVN meta-data. Eric would be better placed to comment here. You are correct, there is nothing practical that can be done in the absence of svn:mergeinfo and svnmerge-integrated properties. My own observation is that when the SVN commits have merge meta-data, reposurgeon will pick this up and create links across to the relevant branches. It does, however seem to create far more links than a traditional git merge would do, especially when a sequence of commits are referenced. I don't know if that's essentially unfixable, or if it's something Eric intends to work on; but I've seen some cases where there are dozens of links back to a simple sequence of svn commits and where, I suspect, a single link back to the most recent of that sequence would be all that's really wanted. First I have heard of this. The intent of the present mergeinfo handing is that it looks for mergeinfo declarations that are topologically equivalent to branch merges (that is, they merge all revisions on a source branch rather than cherry-picking isolated revisions) and rendering those as gitspace merge links. There is no attempt to create links corresponding to Subversion cherry picks, as this does not fit the Git DAG model. I have cases that demonstrate this feature working in my test suite, but they are relatively small and artificial. I would not describe my mergeinfo handling as well-tested compared to the rest of the analyzer, and I can thus easily believe your bug report. What I need to troubleshoot this is a test case that is not trivial but of a manageable size - over a couple hundred commits the volume of diagnostics just overwhelms a Mark One Eyeball. Many of my test cases were trimmed to that size by doing stripping and topological reduction on real repositories; I have a tool for this. Do you have a real repository in mind I can start with? The whole gcc history is too huge, but if you were able to tell me that the bug is exhibited within a few thousand commits of origin and point at where, that I could work with. An issue filed on the reposurgeon tracker would be appreciated. I was looking at the reposurgeon code last night, and I think I can see what the problem *might* be, but I haven't had time to produce a testcase. Some of our commits have mergeinfo that looks a bit like this: 202022-202023,202026,202028-202029,202036,202039-202041,202043-202044,202048-202049,202051-202056,202058-202061,202064-202065,202068-202071,202077,202079-202082,202084,202086-202088,202092-202104,202106-202113,202115-202119,202121,202124-202134,202139,202142-202146,202148-202150,202153-202154,202158-202159,202163-202165,202168,202172,202174,202179-202180,202184-202192,202195,202197,202202-202208,202225-202230,202232-202233,202237-202239,202242,202244-202245,202247,202250-202251,202258-202264,202266,202269,202271-202275,202279,202281-202282,202284,202286,202289-202292,202296-202299,202301-202302,202305,202309,202311-202323,202327-202335,202337,202339,202343-202346,202350,202352,202356-202357,202359-202360,202363-202371,202373-202374,202377,202379-202382,202384,202389,202391-202395,202398-202407,202409,202411,202416-202418,202421 which is a massive long list with a number of holes in it. But I suspect the holes are really commits to other branches and that in the above describes a linear chain along one branch. If so, rather than producing links to each subgroup (and perhaps dropping single non-list elements, the description can be mapped back to a contiguous sequence of commits down a branch and thus should really resolve to a single child being used for the merge source. At present, I think for the above we're seeing a child reference created for each subrange in that list. I'll see if I can construct a real testcase this evening. Incidentally, the mergeinfo pass on the gcc repo is currently taking about 8 hours on my machine, that's 80-90% of the entire conversion time. But it might be related to the above. R.
Lets_s Have a look
Hi, I am curious to know if you would be interested in acquiring a Visitors list of Expo SE 2019. We have 5,000 unique Attendees. Every Contacts include: Contact Name, Email, Job Title, Phone Number etc. Share your thoughts or pass this to concern person. If interested email me back will get back to you with pricing and other information for review Kind Regards, Caroline.Hayes | Lead Generation
Re: Commit messages and the move to git
On Mon, Nov 18, 2019 at 4:38 PM Richard Earnshaw (lists) < richard.earns...@arm.com> wrote: > On 18/11/2019 20:53, Jason Merrill wrote: > > On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool < > > seg...@kernel.crashing.org> wrote: > > > >> On Mon, Nov 18, 2019 at 07:21:22PM +, Richard Earnshaw (lists) > wrote: > >>> On 18/11/2019 18:53, Segher Boessenkool wrote: > PR target/92140: clang vs gcc optimizing with adc/sbb > PR fortran/91926: assumed rank optional > PR tree-optimization/91532: [SVE] Redundant predicated store in > >> gcc.target/aarch64/fmla_2.c > PR tree-optimization/92161: ICE in vect_get_vec_def_for_stmt_copy, at > >> tree-vect-stmts.c:1687 > PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction, > >> at tree-vect-loop.c:4252 > PR c++/92015: internal compiler error: in cxx_eval_array_reference, at > >> cp/constexpr.c:2568 > PR tree-optimization/92173: ICE in optab_for_tree_code, at > >> optabs-tree.c:81 > PR tree-optimization/92173: ICE in optab_for_tree_code, at > >> optabs-tree.c:81 > PR fortran/92174: runtime error: index 15 out of bounds for type > >> 'gfc_expr *[15] > > Most of these aren't helpful at all, and none of these are good commit > summaries. The PR92173 one actually has identical commit messages > btw, > huh. Ah, the second one (r277288) has the wrong changelog, but in the > actual changelog file as well, not something any tool could fix up (or > have we reached the singularity?) > >>> > >>> Identical commits are normally from where the same commit is made to > >>> multiple branches. It's not uncommon to see this when bugs are fixed. > >> > >> This is an actual mistake. The commits are not identical at all, just > >> the commit messages are (and the changelog entries, too). Not something > >> that happens to ften, but of course I hit it in the first random thing I > >> pick :-) > >> > >>> Ultimately the question here is whether something like the above is > more > >>> or less useful than what we have today, which is summary lines of the > >> form: > >>> > >>> > >> > >> I already said I would prefer things like > >> Patch related to PR323 > >> as the patch subject lines. No one argues that the current state of > >> affairs is good. I argue that replacing this with often wrong and > >> irrelevant information isn't the best we can do. > >> > > > > How about using the first line that isn't a ChangeLog date/author line, > > without trying to rewrite/augment it? > > > > Jason > > > > It would certainly be another way of doing it. Sometimes it would > produce almost the same as an unadulterated PR; sometimes it would > produce something more meaningful and sometimes it would be pretty > useless. It probably would hit more cases than my current script in > that it wouldn't require the commit to mention a PR in it. > > The main problem is that the first line is often incomplete, and much of > it is also wasted with elements like the full path to a file that is > quite deep in the tree. Lets take a quick example (the first I found in > the dump I have). > > 1998-12-17 Vladimir N. Makarov > * config/i60/i960.md (extendqihi2): Fix typo (usage ',' instead of > ';'). > 1998-12-17 Michael Tiemann > * i960.md (extend*, zero_extend*): Don't generate rtl that looks > like (subreg:SI (reg:SI N) 0), because it's wrong, and it hides > optimizations from the combiner. > > Firstly, this example misses a blank line between the author and the > change message itself, which makes distinguishing between this and the > multiple authors case harder. Secondly, the entry really spans two > lines and cutting it off at the end of the first line would be, well a > bit odd. We could try to piece things together more, by combining lines > until we find a sentence end ( \.$ or \.\s\s ), and we could also strip > off more of the path components to just leave the name of the file > committed. For example, > > i960.md (extendqihi2): Fix typo (usage ',' instead of ';'). > > That might work better, but obviously it's harder to handle and thus > more likely to create erroneous summaries. > Yep. I don't think we need to worry about getting optimal one-line summaries for ancient commits; something reasonably unique should be plenty.
Re: Commit messages and the move to git
On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote: > Yep. I don't think we need to worry about getting optimal one-line > summaries for ancient commits; something reasonably unique should be plenty. In that case, how about just "SVN rNN"? And then we don't need the footer from git-svn anymore either? And don't need to mangle or wrangle the commit message itself at all either. Segher
Re: Commit messages and the move to git
On Tue, 19 Nov 2019 at 16:31, Segher Boessenkool wrote: > > On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote: > > Yep. I don't think we need to worry about getting optimal one-line > > summaries for ancient commits; something reasonably unique should be plenty. > > In that case, how about just "SVN rNN"? I was about to suggest the same thing.
Re: Commit messages and the move to git
On 19/11/2019 16:31, Segher Boessenkool wrote: On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote: Yep. I don't think we need to worry about getting optimal one-line summaries for ancient commits; something reasonably unique should be plenty. In that case, how about just "SVN rNN"? And then we don't need the footer from git-svn anymore either? And don't need to mangle or wrangle the commit message itself at all either. Segher Sorry, disagree. That's as bad as just the author name, IMO. R.
Re: Commit messages and the move to git
On Tue, Nov 19, 2019 at 11:31 AM Segher Boessenkool < seg...@kernel.crashing.org> wrote: > On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote: > > Yep. I don't think we need to worry about getting optimal one-line > > summaries for ancient commits; something reasonably unique should be > plenty. > > In that case, how about just "SVN rNN"? And then we don't need the > footer from git-svn anymore either? And don't need to mangle or wrangle > the commit message itself at all either. > Well, I was thinking of also giving some clue of what the commit was about. One possibly cut-off line accomplishes that, a simple revision number not so much. Jason
Could unwind landing pads increment the stack?
Hello, I'm looking into how the unwind mechanism works in order to gather information to inform how we should eventually handle exceptions in MTE. I'm currently having a discussion on the llvm-dev list about how HWASAN handles exceptions, and believe it has relevence. https://lists.llvm.org/pipermail/llvm-dev/2019-November/136807.html In the above email Peter brings up two hypothetical cases where an unwind landing pad increments the stack pointer before calling _Unwind_Resume. I have not found anything in the relevant ABI documents that discounts this possibility, but I am wondering if it happens in practice. (if this does happen in practice, then there would be extra work if the ABI were strengthened to ban this on MTE tagged functions). Does anyone know if GCC could emit such a landing pad? Cheers, MM
Re: Commit messages and the move to git
Richard Earnshaw (lists) : > I was looking at the reposurgeon code last night, and I think I can see what > the problem *might* be, but I haven't had time to produce a testcase. > > Some of our commits have mergeinfo that looks a bit like this: > > 202022-202023,202026,202028-202029,202036,202039-202041,202043-202044,202048-202049,202051-202056,202058-202061,202064-202065,202068-202071,202077,202079-202082,202084,202086-202088,202092-202104,202106-202113,202115-202119,202121,202124-202134,202139,202142-202146,202148-202150,202153-202154,202158-202159,202163-202165,202168,202172,202174,202179-202180,202184-202192,202195,202197,202202-202208,202225-202230,202232-202233,202237-202239,202242,202244-202245,202247,202250-202251,202258-202264,202266,202269,202271-202275,202279,202281-202282,202284,202286,202289-202292,202296-202299,202301-202302,202305,202309,202311-202323,202327-202335,202337,202339,202343-202346,202350,202352,202356-202357,202359-202360,202363-202371,202373-202374,202377,202379-202382,202384,202389,202391-202395,202398-202407,202409,202411,202416-202418,202421 > > which is a massive long list with a number of holes in it. > > But I suspect the holes are really commits to other branches and that in the > above describes a linear chain along one branch. If so, rather than > producing links to each subgroup (and perhaps dropping single non-list > elements, the description can be mapped back to a contiguous sequence of > commits down a branch and thus should really resolve to a single child being > used for the merge source. At present, I think for the above we're seeing a > child reference created for each subrange in that list. I have no doubt you are correct. Detecting such interrupted ranges ia foing to be... interesting. > Incidentally, the mergeinfo pass on the gcc repo is currently taking about 8 > hours on my machine, that's 80-90% of the entire conversion time. But it > might be related to the above. You must be running the old Python code, there was on O(n**2) in that phase that has since been fixed. Try the Go code from https://gitlab.com/esr/reposurgeon; it is *much* faster. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Commit messages and the move to git
Jason Merrill : > Well, I was thinking of also giving some clue of what the commit was > about. One possibly cut-off line accomplishes that, a simple revision > number not so much. It's conventional under Git to have comments lead with a summary sentence. I think you're going to find that the value of Subversion revision references fades pretty fast after the conversion. That has been my experience with other conversions. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Commit messages and the move to git
On 19/11/2019 11:45, Richard Earnshaw (lists) wrote: > On 19/11/2019 11:24, Eric S. Raymond wrote: >> Richard Earnshaw (lists) : >>> Well a lot of that is a property of the conversion tool. git svn does a >>> relatively poor job of anything other than straight history (I >>> believe it >>> just ignores the non-linear information. >> >> Yes, svn-git does a *terrible* job on anything other than linear history. >> >> That is a major reason I'm busting my hump to get the conversion done. >> It would be very sad if you guys fell into using that. It does a >> tolerable job of live gatewaying on simple histories, but read this: >> >> http://esr.ibiblio.org/?p=6778 >> >>> I don't believe any tool can >>> recreate information for cherry-picking unless it's recorded in the SVN >>> meta-data. Eric would be better placed to comment here. >> >> You are correct, there is nothing practical that can be done in the >> absence >> of svn:mergeinfo and svnmerge-integrated properties. >> >>> My own observation is that when the SVN commits have merge meta-data, >>> reposurgeon will pick this up and create links across to the relevant >>> branches. It does, however seem to create far more links than a >>> traditional >>> git merge would do, especially when a sequence of commits are >>> referenced. I >>> don't know if that's essentially unfixable, or if it's something Eric >>> intends to work on; but I've seen some cases where there are dozens >>> of links >>> back to a simple sequence of svn commits and where, I suspect, a >>> single link >>> back to the most recent of that sequence would be all that's really >>> wanted. >> >> First I have heard of this. >> >> The intent of the present mergeinfo handing is that it looks for >> mergeinfo declarations that are topologically equivalent to branch >> merges (that is, they merge all revisions on a source branch rather >> than cherry-picking isolated revisions) and rendering those as >> gitspace merge links. There is no attempt to create links >> corresponding to Subversion cherry picks, as this does not fit >> the Git DAG model. >> >> I have cases that demonstrate this feature working in my test suite, >> but they are relatively small and artificial. I would not describe >> my mergeinfo handling as well-tested compared to the rest of the >> analyzer, and I can thus easily believe your bug report. >> >> What I need to troubleshoot this is a test case that is not trivial >> but of a manageable size - over a couple hundred commits the volume >> of diagnostics just overwhelms a Mark One Eyeball. >> >> Many of my test cases were trimmed to that size by doing stripping and >> topological reduction on real repositories; I have a tool for this. >> Do you have a real repository in mind I can start with? The whole gcc >> history is too huge, but if you were able to tell me that the bug is >> exhibited within a few thousand commits of origin and point at where, >> that I could work with. >> >> An issue filed on the reposurgeon tracker would be appreciated. >> > > I was looking at the reposurgeon code last night, and I think I can see > what the problem *might* be, but I haven't had time to produce a testcase. > > Some of our commits have mergeinfo that looks a bit like this: > > 202022-202023,202026,202028-202029,202036,202039-202041,202043-202044,202048-202049,202051-202056,202058-202061,202064-202065,202068-202071,202077,202079-202082,202084,202086-202088,202092-202104,202106-202113,202115-202119,202121,202124-202134,202139,202142-202146,202148-202150,202153-202154,202158-202159,202163-202165,202168,202172,202174,202179-202180,202184-202192,202195,202197,202202-202208,202225-202230,202232-202233,202237-202239,202242,202244-202245,202247,202250-202251,202258-202264,202266,202269,202271-202275,202279,202281-202282,202284,202286,202289-202292,202296-202299,202301-202302,202305,202309,202311-202323,202327-202335,202337,202339,202343-202346,202350,202352,202356-202357,202359-202360,202363-202371,202373-202374,202377,202379-202382,202384,202389,202391-202395,202398-202407,202409,202411,202416-202418,202421 > > > which is a massive long list with a number of holes in it. > > But I suspect the holes are really commits to other branches and that in > the above describes a linear chain along one branch. If so, rather than > producing links to each subgroup (and perhaps dropping single non-list > elements, the description can be mapped back to a contiguous sequence of > commits down a branch and thus should really resolve to a single child > being used for the merge source. At present, I think for the above > we're seeing a child reference created for each subrange in that list. > > I'll see if I can construct a real testcase this evening. > > Incidentally, the mergeinfo pass on the gcc repo is currently taking > about 8 hours on my machine, that's 80-90% of the entire conversion > time. But it might be related to the above. > > R. > I've been unsuc
Re: Commit messages and the move to git
On 19/11/2019 19:32, Eric S. Raymond wrote: > Richard Earnshaw (lists) : >> I was looking at the reposurgeon code last night, and I think I can see what >> the problem *might* be, but I haven't had time to produce a testcase. >> >> Some of our commits have mergeinfo that looks a bit like this: >> >> 202022-202023,202026,202028-202029,202036,202039-202041,202043-202044,202048-202049,202051-202056,202058-202061,202064-202065,202068-202071,202077,202079-202082,202084,202086-202088,202092-202104,202106-202113,202115-202119,202121,202124-202134,202139,202142-202146,202148-202150,202153-202154,202158-202159,202163-202165,202168,202172,202174,202179-202180,202184-202192,202195,202197,202202-202208,202225-202230,202232-202233,202237-202239,202242,202244-202245,202247,202250-202251,202258-202264,202266,202269,202271-202275,202279,202281-202282,202284,202286,202289-202292,202296-202299,202301-202302,202305,202309,202311-202323,202327-202335,202337,202339,202343-202346,202350,202352,202356-202357,202359-202360,202363-202371,202373-202374,202377,202379-202382,202384,202389,202391-202395,202398-202407,202409,202411,202416-202418,202421 >> >> which is a massive long list with a number of holes in it. >> >> But I suspect the holes are really commits to other branches and that in the >> above describes a linear chain along one branch. If so, rather than >> producing links to each subgroup (and perhaps dropping single non-list >> elements, the description can be mapped back to a contiguous sequence of >> commits down a branch and thus should really resolve to a single child being >> used for the merge source. At present, I think for the above we're seeing a >> child reference created for each subrange in that list. > > I have no doubt you are correct. Detecting such interrupted ranges ia > foing to be... interesting. > >> Incidentally, the mergeinfo pass on the gcc repo is currently taking about 8 >> hours on my machine, that's 80-90% of the entire conversion time. But it >> might be related to the above. > > You must be running the old Python code, there was on O(n**2) in that > phase that has since been fixed. Try the Go code from > https://gitlab.com/esr/reposurgeon; it is *much* faster. > Nope, that was from running the go version from yesterday. This one, to be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637 This pass used to be very fast a couple of weeks back, but something went in recently that's caused a major slowdown. Oh, and I've been having problems with the ChangeLogs command as well. It used to run fine on my machine (128G), but now it's started blowing memory and taking my X server down. R. R.
Re: Commit messages and the move to git
On 19/11/2019 19:47, Richard Earnshaw (lists) wrote: > On 19/11/2019 19:32, Eric S. Raymond wrote: >> Richard Earnshaw (lists) : >>> I was looking at the reposurgeon code last night, and I think I can see what >>> the problem *might* be, but I haven't had time to produce a testcase. >>> >>> Some of our commits have mergeinfo that looks a bit like this: >>> >>> 202022-202023,202026,202028-202029,202036,202039-202041,202043-202044,202048-202049,202051-202056,202058-202061,202064-202065,202068-202071,202077,202079-202082,202084,202086-202088,202092-202104,202106-202113,202115-202119,202121,202124-202134,202139,202142-202146,202148-202150,202153-202154,202158-202159,202163-202165,202168,202172,202174,202179-202180,202184-202192,202195,202197,202202-202208,202225-202230,202232-202233,202237-202239,202242,202244-202245,202247,202250-202251,202258-202264,202266,202269,202271-202275,202279,202281-202282,202284,202286,202289-202292,202296-202299,202301-202302,202305,202309,202311-202323,202327-202335,202337,202339,202343-202346,202350,202352,202356-202357,202359-202360,202363-202371,202373-202374,202377,202379-202382,202384,202389,202391-202395,202398-202407,202409,202411,202416-202418,202421 >>> >>> which is a massive long list with a number of holes in it. >>> >>> But I suspect the holes are really commits to other branches and that in the >>> above describes a linear chain along one branch. If so, rather than >>> producing links to each subgroup (and perhaps dropping single non-list >>> elements, the description can be mapped back to a contiguous sequence of >>> commits down a branch and thus should really resolve to a single child being >>> used for the merge source. At present, I think for the above we're seeing a >>> child reference created for each subrange in that list. >> >> I have no doubt you are correct. Detecting such interrupted ranges ia >> foing to be... interesting. >> >>> Incidentally, the mergeinfo pass on the gcc repo is currently taking about 8 >>> hours on my machine, that's 80-90% of the entire conversion time. But it >>> might be related to the above. >> >> You must be running the old Python code, there was on O(n**2) in that >> phase that has since been fixed. Try the Go code from >> https://gitlab.com/esr/reposurgeon; it is *much* faster. >> > > Nope, that was from running the go version from yesterday. This one, to > be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637 > > This pass used to be very fast a couple of weeks back, but something > went in recently that's caused a major slowdown. > > Oh, and I've been having problems with the ChangeLogs command as well. > It used to run fine on my machine (128G), but now it's started blowing > memory and taking my X server down. > > R. > > R. > Here's the stats output: # Statistics on read and processing times timing commits:276738 (from 278380) parsing:2.85% 14m22.861991058s cleaning:0.32% 1m37.653100823s filemaps:0.37% 1m52.851558995s commits:4.40% 22m15.380157228s rootcommit:0.00% 8.779µs branches:0.04% 12.710113776s parents:0.00% 121.73484ms root:0.00% 267.997µs branchlinks:0.00% 10.58361ms mergeinfo:91.67% 7h43m15.416510183s branches:0.00% 11.616µs dejunk:0.04% 10.672889443s polishing:0.04% 11.249533399s tagifying:0.03% 10.528735532s tagcleaning:0.03% 9.880052536s debubbling:0.00% 1.384357053s renumbering:0.20% 59.718288526s total:9/sec 8h25m20.439895394s
Re: Commit messages and the move to git
Richard Earnshaw (lists) : > I've been unsuccessful so far in creating a simple reproducer. However, > r278216 on the gcc 'ranger' branch is an example of what I mean. The > property list for this is > > $ svn propget svn:mergeinfo -r278216 > FILE:///home/rearnsha/tmp/gcc-mirror/branches/ranger > /trunk:274955-274956,274958,274961-274962,274964,274966,274975-274976,274980-274988,274990-274992,274994,274996-275000,275004-275005,275007-275012,275021-275023,275025-275028,275030-275032,275034,275049-275050,275055,275059,275062-275063,275174,275177-275178,275187-275188,275190-275191,275195-275200,275204-275205,275210-275211,275223,275227,275231,275235-275240,275242-275243,275258,275260,275264-275271,275274,275284-275285,275290-275293,275295,275297-275299,275303,275313-275316,275318,275320,275322,275324,275328-275338,275341-275344,275352-275358,275362,275364-275365,275367-275369,275376-275377,275387-275391,275395-275404,275406,275408-275409,275411,275414,275421,275426,275442,275444,275449-275450,275452-275458,275460,275462,275464,275472-275473,275475-275478,275482-275484,275486,275488-275489,275493,275497,275501-275508,275513-275514,275517-275518,275521-275522,275524-275537,275539-275541,275544,275551,27,275557-275589,275591-275594,275597-275606,275608,275611,275613,275617,275622,275631-275635,275639-275644,275648,275650-275652,275655,275657,275667,275680,275682-275683,275685,275689,275691,275695-275704,275709,275713,275717-275719,275723,275726-275727,275729-275731,275735-275736,275741,275743-275755,275757-275759,275763,275768-275800,275802-275809,275813-275814,275833,275836-275875,275896-275899,275901,275905-275907,275919,275924-275926,275928,275930-275972,275976-275979,275981-275982,275986,275989-275990,275992,275994,275996,275998-275999,276001-276002,276004,276006-276007,276011,276015,276017-276022,276026-276027,276030,276035-276036,276041,276045-276059,276063-276065,276085,276089,276091-276100,276102-276103,276105-276107,276111-276112,276119-276123,276125,276127-276128,276132-276135,276139-276159,276162-276168,276172-276180,276183-276184,276186-276188,276190-276193,276196,276211-276213,276227-276228,276236,276240,276244,276248-276249,276251,276253-276256,276260,276264-276272,276276,276294-276341,276343,276359-276361,276371-276376,276380,276382,276386-276389,276391-276396,276401-276405,276407-276411,276415-276418,276420,276422,276424,276426-276434,276438-276449,276452-276457,276459,276461-276466,276468-276474,276479,276484,276487-276489,276491-276498,276502-276508,276510,276515-276516,276518-276519,276525,276527,276530,276532,276539,276542-276543,276555-276556,276560-276564,276566-276568,276571-276572,276574-276577,276579-276582,276584-276585,276587-276597,276600-276603,276605,276618,276621-276624,276626-276627,276629-276630,276634-276640,276644-276645,276648-276651,276653-276655,276657-276661,276663-276665,276668,276670-276671,276674-276675,276679-276681,276685-276686,276688-276695,276698,276700,276702-276703,276705-276709,276711,276721-276722,276725,276750-276758,276760,276762-276764,276766-276768,276770-276771,276773,276786-276787,276789-276792,276796,276804,276807-276824,276826-276836,276839-276843,276846-276851,276854,276858-276861,276864-276866,276870-276876,276878,276882,276885-276892,276894,276896-276903,276906-276908,276912-276916,276920-276926,276928,276933-276943,276947-276956,276958-276964,276967-276972,276976-276978,276982-277000,277005,277008-277011,277015,277023,277033,277049,277054,277056-277063,277065,277067-277068,277070-277071,277073,277076,277080,277082-277084,277088-277103,277105,277107-277108,277110-277115,277120-277121,277126,277128-277130,277133-277135,277140-277143,277150-277151,277153,277155-277158,277164-277192,277194,277199-277205,277209-277211,277214-277217,277221,277223-277241,277260-277262,277264,277266-277268,277270-277271,277276-277293,277297,277299-277302,277306-277311,277313-277314,277320-277323,277333,277335-277349,277351-277352,277358,277362-277363,277365-277369,277371-277375,277394-277395,277403-277404,277406-277410,277415-277416,277419,277421,277424-277427,277433-277438,277440-277442,277446,277448-277451,277455,277458-277459,277462,277468-277470,277472,277475-277476,277480-277487,277491-277492,277499,277501-277504,277507-277510,277512-277514,277516-277517,277524-277525,277527,277533-277535,277537,277544-277546,277550-277569,277571-277573,277575-277579,277588-277589,277591-277593,277595,277599-277607,277609-277610,277612-277624,277627-277637,277639,277643,277648-277649,277653-277664,277666-277667,277672,277674-277686,277697-277699,277703-277709,277711,277714-277715,277719,277723,277728,277730,277732-277735,277740-277743,277749,277752-277760,277764,277766-277769,21-277780,277782,277784-277799,277801,277810,277812-277824,277826-277839,277845-277854,277859-277866,277870-277873,277875-277893,277895,277899-277936,277940-277956,277958-277966,277969,277972-277979,277990-277991,277993-277995,277999-278000,278003-278009,278013,278016-278017,278019-278028,278032-278035,2
Re: Commit messages and the move to git
Richard Earnshaw (lists) : > Nope, that was from running the go version from yesterday. This one, to > be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637 > > This pass used to be very fast a couple of weeks back, but something > went in recently that's caused a major slowdown. > > Oh, and I've been having problems with the ChangeLogs command as well. > It used to run fine on my machine (128G), but now it's started blowing > memory and taking my X server down. That sucks. Those were stretches of code the two guys working with me have been trying to speed up. Looks like that backfired. Please file isses at https://gitlab.com/esr/reposurgeon/issues and include timing reports if you can. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Commit messages and the move to git
On 19/11/2019 22:14, Eric S. Raymond wrote: > Richard Earnshaw (lists) : >> Nope, that was from running the go version from yesterday. This one, to >> be precise: 1ab3c514c6cd5e1a5d6b68a8224df299751ca637 >> >> This pass used to be very fast a couple of weeks back, but something >> went in recently that's caused a major slowdown. >> >> Oh, and I've been having problems with the ChangeLogs command as well. >> It used to run fine on my machine (128G), but now it's started blowing >> memory and taking my X server down. > > That sucks. Those were stretches of code the two guys working with me > have been trying to speed up. Looks like that backfired. > > Please file isses at https://gitlab.com/esr/reposurgeon/issues and > include timing reports if you can. > OK I'll see if I can narrow the offending commit down a bit first. I have a rough idea when each occurred, but I haven't pinpointed a precise commit. R.
Re: ToDos on Parallel GCC Wiki
On 11/18/19 3:44 PM, Nicholas Krause wrote: Greetings Richard, Seems some of these things can either be closed or discussed here: Add support to a multithread environment to Garbage Collector: This may not matter as memory is in bulk at the beginning of passes. I've benchmarked it and its less than 5% on the GCC test farm machines with make -j64. Parallelize RTL part. This will improve our current results, as indicated in Results chapter: struct function or function.c if I recall is using the most as one file at around 20-30% for sure in building gcc with make -j64. Make this GCC compile itself: It does now and I just tested it but I assuming he means with threads on and I'm not sure how to enable them in the core Makefile for gcc or if just exporting CC/CXX is earlier with it turned on. I've also looked into the Linux Kernel work queues as those can scale much better than just launching in async as we are doing currently. On the testingside seems the Yocto Project is working on testing upstream heads of projects like gcc. I've asked them to bring it up at the usual IOT/Embedded Linux Conference meeting. This will also us to have access to not only the gcc testsuite but access to build lots of real world software packages in a pretty automated way as that was one concern that Giuliano brought up at the Cauldron this year. Also if someone opens a more detailed ToDo with Bugs or something I would be able to help out more or just CC on the issues or work that is ongoing as frankly seems I'm not been keeping good track, Nick Sorry Richard but seems but email client was formatting it incorrectly, Seems some of these things can either be closed or discussed here: Add support to a multithread environment to Garbage Collector:This may not matter as memory is in bulk at the beginning of passes. I've benchmarkedit and its less than 5% on the GCC test farm machines with make -j64.Parallelize RTL part. This will improve our current results, as indicated in Results chapter:struct function or function.c if I recall is using the most as one file at around 20-30% forsure in building gcc with make -j64. Make this GCC compile itself: It does now and I just tested it but I assuming he means with threads on and I'm not sure how to enable them in the core Makefile for gcc or if just exporting CC/CXX is earlier with it turned on.I've also looked into the Linux Kernel work queues as those can scale much better than just launching in async as we are doing currently. On the testing side seems the Yocto Project is working on testing upstream heads of projects like gcc. I've asked them to bring it up at the usual IOT/Embedded Linux Conference meeting. This will also us to have access to not only the gcc testsuite but access to build lots of real world software packages in a pretty automated way as that was one concern that Giuliano brought up at the Cauldron this year. Also if someone opens a more detailed ToDo with Bugs or something I would be able to help out more or just CC on the issues or work that is ongoing as frankly seems I'm not been keeping good track, Nick
Re: Commit messages and the move to git
On Tue, Nov 19, 2019 at 02:36:21PM -0500, Eric S. Raymond wrote: > Jason Merrill : > > Well, I was thinking of also giving some clue of what the commit was > > about. One possibly cut-off line accomplishes that, a simple revision > > number not so much. Sure, but it isn't easy at all to automatically come up with anything useful or close to correct. But if you start the subject line with the SVN revision number, it is very useful. > It's conventional under Git to have comments lead with a summary sentence. > > I think you're going to find that the value of Subversion revision references > fades pretty fast after the conversion. That has been my experience with > other conversions. Bugzilla is filled to the brim with SVN revision numbers. This won't lose relevance any time soon. Decades of history. Most of the time after I type "git log" I type "/\<123456\>". We need to keep a way to easily map SVN revision ids to git commits, and something a bit more elegant than the ugly git-svn footers would be nice. Segher
Re: Commit messages and the move to git
On Tue, 19 Nov 2019, Segher Boessenkool wrote: > Most of the time after I type "git log" I type "/\<123456\>". We need > to keep a way to easily map SVN revision ids to git commits, and > something a bit more elegant than the ugly git-svn footers would be nice. Whatever reposurgeon's "write --legacy" yield seems appropriate for making the SVN revision ids readily available in the commit messages. I don't think the summary line is a good place for that information. I do think "Related to PR N (description)" or similar is a good summary line to insert where the present summary line is just a ChangeLog date/author line. -- Joseph S. Myers jos...@codesourcery.com
Re: Commit messages and the move to git
On 11/19/19 6:44 PM, Joseph Myers wrote: On Tue, 19 Nov 2019, Segher Boessenkool wrote: Most of the time after I type "git log" I type "/\<123456\>". We need to keep a way to easily map SVN revision ids to git commits, and something a bit more elegant than the ugly git-svn footers would be nice. Whatever reposurgeon's "write --legacy" yield seems appropriate for making the SVN revision ids readily available in the commit messages. I don't think the summary line is a good place for that information. I do think "Related to PR N (description)" or similar is a good summary line to insert where the present summary line is just a ChangeLog date/author line. Sorry for pointing this out if it was not obvious but Related to PR N or commit id in the message is fine. You would have to figure out whether the git id is more important or the PR for each commit as normally only one of these is used. Normally in my experience git bisect or revert use ids directly but everything else can just use the ported svn or PR from Bugzilla. It really depends but the ids are more for if your dealing with the projects history itself rather than just a bug on the bugzilla. That's just my opinion through so take it wait a grain of salt, Nick
