> -----Original Message----- > From: Thomas Schwinge <tschwi...@baylibre.com> > Sent: Monday, July 28, 2025 11:05 > To: Robert Dubner <rdub...@symas.com> > Cc: Richard Biener <rguent...@suse.de>; Andreas Schwab <sch...@suse.de>; > David > Malcolm <dmalc...@redhat.com>; gcc@gcc.gnu.org; gcc-patc...@gcc.gnu.org; > James > K. Lowden <jklow...@cobolworx.com> > Subject: RE: GCC 15.1.1 Status Report (2025-07-11) > > Hi Bob! > > On 2025-07-27T16:00:29-0500, Robert Dubner <rdub...@symas.com> wrote: > > I am throwing in the towel. > > > > I am chalking up the hours I have spent on this as a positive on the > > educational side of the ledger. I have learned things about > > git-cherry-pick, git-rev-list, and git-log that I didn't know, and > > that's > > good. > > > > I have reached the point where I am convinced that what I would like to > > do > > is not just hard, but impractical. I got to this point: > > > > git switch -C patched15 gcc/releases/gcc-15 > > git cherry-pick -x \ > > $(git rev-list basepoints/gcc-16..gcc/master \ > > --invert-grep --grep="Daily bump" \ > > -- libgcobol gcc/cobol gcc/testsuite/cobol.dg) > > > > That rev-list command produces a list of all the commits since The > > Beginning > > Of GCC-16 that touch files in libgcobol/, gcc/cobol/ and > > gcc/testsuite/cobol.dg, which is what I wanted. But the result is > > numerous > > conflicts. > > Hmm, I'm not seeing that? > > > I had to exclude the "Daily bump" commits because the ones that affect > > gcc/cobol/ChangeLog or libgcobol/ChangeLog tend to modify many other > > ChangeLogs as well, leading to conflicts. > > Right, those need to be excluded. > > > But even with that filter, numerous other conflicts arise. Thirty-two > > of > > them, as a matter of fact. Exactly one of them is in a gcc/cobol cobol > > file; the rest are in other source code trees. > > > > Many of those conflicts occurred because of wide-ranging commits that > > change > > not just gcc/cobol files, but files in other source trees. (I am > > looking at > > you, David Malcolm; your changes to the diagnostics cut quite the swath > > through the GCC source code.) > > Well, that happens. :-) But: mass-refactoring to improve the overall > code organization etc. certainly has a very high merit on its own, so > that's OK to cause some "collateral damage". > > But then: those commits aren't applicable for GCC 15 backporting anyway, > so just 'git cherry-pick --skip' those. > > I just executed (a variant of) what I had in my other email: > > $ rev_start=origin/releases/gcc-15 # Will be different next time. > $ git log --reverse --stat -p --regexp-ignore-case --grep=cobol > "$rev_start"..origin/trunk > > I 'git cherry-pick --skip'ed the (few, just two?) commits that had alread > made it into releases/gcc-15 branch, and 'git cherry-pick --skip'ed the > last few diagnostics-related ones, and: everything else of those > GCC/Cobol commits 'git cherry-pick -x'ed without any conflicts. > > I'm happy to put that branch into my usual testing, and/or publish it for > anyone to test, if you still see value in that. (..., and unless you'd > like to reproduce that yourself.) ;-) > > > Grüße > Thomas
I would like to know exactly what you did. Did you create a list of commit hashes that you then attempted to cherry-pick, one at a time, so that you could evaluate each result and decide to skip it or not?
