Re: git magic or usage wisdom.
On Thu, Aug 4, 2022 at 1:58 PM Ismael Luceno wrote: > > On 04/Aug/2022 13:24, jim.cro...@gmail.com wrote: > > so I have this patchset (sent to lkml recently ), > > it adds a new struct: > > struct _ddebug_info > <...> > > is there some git command magic to work this ? > > > > in a pre-git world, I might try > > perl -pi -e 's/_ddebug_info/_ddebug_stateinfo/g' 00*.patch > > > > that "might" work, but could also create a myriad of conflicts > > when the patchset is 'git am' d > > and it might apply clean but still break on compile ? > > > > anyone care to opine on the probability of success ? > > > > If I try this, I'll report back. > > ISTM more likely than my doing it manually. > > The approach is fine :). > thanks for the confirm, and I like the ^+ filter, and the \b's it limits the modifications tightly. > Whatever you do, you can't escape testing that the patches apply and > compile... > indeed. its embarrassing when crap escapes the lab. > What you may simplify is the editing by chaining the commands to > replay changes into a new branch: > > git format-patch -k --stdout base..old-branch | > perl -pe '...' | git am -3 -k > > Further automation seems counterproductive. > that pipeline is helpful, I will play with it. > As for the editing, I would use the following perl code: > > if (/^\+/) { s/\b_ddebug_info\b/_ddebug_stateinfo/g } > > That way you limit edits only to new content, and the struct name is > properly bounded by the regex. > > I guess that's about as robust as you can make it without going out of > your way. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: git magic or usage wisdom.
On 04/Aug/2022 13:24, jim.cro...@gmail.com wrote: > so I have this patchset (sent to lkml recently ), > it adds a new struct: > struct _ddebug_info <...> > is there some git command magic to work this ? > > in a pre-git world, I might try > perl -pi -e 's/_ddebug_info/_ddebug_stateinfo/g' 00*.patch > > that "might" work, but could also create a myriad of conflicts > when the patchset is 'git am' d > and it might apply clean but still break on compile ? > > anyone care to opine on the probability of success ? > > If I try this, I'll report back. > ISTM more likely than my doing it manually. The approach is fine :). Whatever you do, you can't escape testing that the patches apply and compile... What you may simplify is the editing by chaining the commands to replay changes into a new branch: git format-patch -k --stdout base..old-branch | perl -pe '...' | git am -3 -k Further automation seems counterproductive. As for the editing, I would use the following perl code: if (/^\+/) { s/\b_ddebug_info\b/_ddebug_stateinfo/g } That way you limit edits only to new content, and the struct name is properly bounded by the regex. I guess that's about as robust as you can make it without going out of your way. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
git magic or usage wisdom.
so I have this patchset (sent to lkml recently ), it adds a new struct: struct _ddebug_info dyndbg: create and use struct _ddebug_info this new struct gathers the linker provided vectors/sections: descs - the vector of descriptors in __dyndbg section. num_descs - length of the data/section If I had an endless supply of free do-overs, Id change the name to something a little less user-facing, since its meant to ref the whole dyndbg-config-state is there some git command magic to work this ? in a pre-git world, I might try perl -pi -e 's/_ddebug_info/_ddebug_stateinfo/g' 00*.patch that "might" work, but could also create a myriad of conflicts when the patchset is 'git am' d and it might apply clean but still break on compile ? anyone care to opine on the probability of success ? If I try this, I'll report back. ISTM more likely than my doing it manually. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies