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

[Josh Triplett <josh@joshtriplett.org>]

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.

> > I'm tempted to add a "git series filter" that applies filter-branch to
> > the commits in the series, or something similar to that.  I'll also have
> > to think about the use case of testing each commit in the series, to see
> > if that needs support from git-series or just from underlying git tools.
> 
> Another one I really started to like is that you can visually compare
> changes to a patch. It takes a bit of experience reading them, but
> after a while diffs-of-patches start to make as much sense as a plain
> patch, e.g.
> - Context movements easily stand out, they only touch @@ lines or
> lines not starting in +/-.
> - Rebasing adjustements in the patch itself (in the + lines of the patch).
> - Direct code conflicts with upstream (anything that changes a - line
> in the patch).
> 
> I think that's the other massive benefit of working on a pile of patches.

That's actually the output I'm planning to provide for "git series diff"
or "git series log -p" to show the diff between patch series.

> But the problem is that all three (bisecting, sed on raw patches and
> patch-diffs) are only really useful if you have to maintain a rebasing
> tree over a really long time (months/years). I think for a normal
> feature patch series your git series is more than sufficient.

I'd like git-series to work for both workflows.  The feature patch case
is definitely easier, but I'd like to support long-standing rebasing
trees too.  Use cases include maintainer trees like yours, as well as
distribution packaging repositories with patches, and vendor/product
kernels.

> PS: Since we work for the same company I can actually show you the
> internal branch if you're interested in how this works ;-)

Definitely interested; perhaps when I'm back from sabbatical. :)

- Josh Triplett