Re: [Ksummit-discuss] [ANNOUNCE] git-series: track changes to a patch series over time

["Luis R. Rodriguez" <mcgrof@kernel.org>]

On Fri, Jul 29, 2016 at 09:21:04AM -0700, Josh Triplett wrote:
> On Fri, Jul 29, 2016 at 05:40:05PM +0200, Daniel Vetter wrote:
> > On Fri, Jul 29, 2016 at 5:18 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> > > On Fri, Jul 29, 2016 at 05:00:06PM +0200, Daniel Vetter wrote:
> > >> And the other reason is the same you have: Editing raw patches is
> > >> really powerful for doing rebases over mechanical changes. Function
> > >> renames become a trivial quilt pop -a ; sed; while quilt push ; do
> > >> make ; done.
> > >
> > > Interesting!  I'll have to give that some thought, to figure out if
> > > I can support workflows like that.
> > >
> > > What other kinds of changes do you tend to make by editing patches
> > > directly?
> > 
> > The other upshot of raw patches is that you can use horrible risky
> > tools like wiggle to force a patch to apply. git is a lot more strict
> > and ime wiggle helps you with a lot of simple rebase conflicts. I have
> > small helper scripts to integrate wiggle both into that quilt flow
> > script, but also into normal git rebase.
> 
> That does sound useful.  It'd be nice to have "git apply --wiggle" and
> "git am --wiggle", too.

A bigger pipe dream is inference of SmPL grammar of a patch, then use
SmPL to address the rebase. Inference work is in theory possible and
R&D is ongoing in that direction. That should make this scale.

  Luis