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

[Daniel Vetter <daniel.vetter@ffwll.ch>]

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:
>> On Fri, Jul 29, 2016 at 4:21 PM, Christoph Lameter <cl@linux.com> wrote:
>> > On Fri, 29 Jul 2016, David Howells wrote:
>> >
>> >> Josh Triplett <josh@joshtriplett.org> wrote:
>> >>
>> >> > Note that git-series doesn't provide a quilt-style push/pop workflow,
>> >> > with applied and unapplied patches; it just looks at HEAD.
>> >>
>> >> Ah...  In that case it's probably not a sufficient substitute for how I use
>> >> stgit.
>> >
>> > Did not know that there was stgit. Still stuck on quilt since
>> > I like editing the files directly (its often easier to edit the diffs if
>> > you want to rename things etc).
>> >
>> > Interesting projects.
>>
>> Shameless plug of our own tooling for maintainer a quilt pile and
>> tracking it in git:
>>
>> https://cgit.freedesktop.org/drm-intel/tree/qf?h=maintainer-tools
>>
>> It even tracks the baseline sha1 and pulls/pushes it in hidden remote
>> refs/. Which all together allows you to git bisect on the quilt
>> branch, which is a really powerful thing for a long-lived rebasing
>> patch pile. quilt+git was the only thing that allowed me to glue
>> something git bisect capable together.
>
> By "bisect on the quilt branch", do you mean bisecting between versions
> of the overall patch series?

Yes. I can't show you a live branch because it's internal, but in the
patches/ directory managed by quilt there's 2 additional things:
- .git dir to manage just teh patches directory as a git branch
- config file which only stores the baseline sha1

The parent source dir is any git repo you want really.

There's convenience commands to rebase to a new baseline sha1 in the
parent repo and adjust the quilt branch accordingly. And there's a
special checkout command to check out the current baseline into the
parent repo and then apply the quil patches on top. As long as you run
that before you test a revision git bisect wants you to test, you can
bisect on the quilt branch.

The other magic bit is that it stores the quilt branch in
refs/quilt-branches (also synced in the remote) and the baselines as
tags in refs/quilt-tags, plus it keeps the two .git directories
somewhat in sync. That way you can git push/pull and both the quilt
branch _and_ all the baseline tags needed to reconstruct each commit
get transferred. But since it's a special refs/quilt-* namespace this
is only done when you run the setup command. Anyone using plain git
only observes a normal rebasing git branch and none of the underlying
magic.

> That does seem quite helpful, if you need to figure out at what point a
> change occurred in the patch series to break something.  I've filed
> https://github.com/git-series/git-series/issues/3 about supporting that.
>
>> 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.

> 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.

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.
-Daniel

PS: Since we work for the same company I can actually show you the
internal branch if you're interested in how this works ;-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch