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.
On 04/Aug/2022 13:24, jim.cromie@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.
On Thu, Aug 4, 2022 at 1:58 PM Ismael Luceno <ismael@iodev.co.uk> wrote:
On 04/Aug/2022 13:24, jim.cromie@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.
participants (2)
-
Ismael Luceno -
jim.cromie＠gmail.com