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

[James Hogan <james.hogan@imgtec.com>]

[-- Attachment #1: Type: text/plain, Size: 5317 bytes --]

On Mon, Aug 15, 2016 at 02:35:37PM -0700, Josh Triplett wrote:
> On Mon, Aug 15, 2016 at 07:46:47PM +0100, James Hogan wrote:
> > The metadata for my current workflow would be a set of other series that
> > each series is dependent on (usually 1, but sometmes more if there are
> > series for different subsystems, which need merging together before the
> > base of the new series).
> > 
> > If I update one of the earlier series, I'd normally just rebase all the
> > others on top one by one (git rebase -p --onto HEAD <base> <branch>). It
> > gets a bit repetative, but with tig alongside showing the graph with
> > commit ids, and -p to preserve merges when necessary, and diffing to
> > sanity check changes, its doable.
> > 
> > git-series could make that easier as I could just "git series rebase
> > otherbranch" without having to check the commit id for the base, asside
> > from when it contains merges of course.
> 
> Would it help to suport "git series rebase seriesname" to rebase on top
> of a series?
> 
> Actually you can do that today with "git series rebase
> git-series/seriesname:series", thanks to git's "extended" syntax.
> Still, probably a good idea to support a shorter syntax like "git series
> rebase seriesname" as well.

Right, I've already done it using a branch with the same name as the
series, so unless the default branch name is different I guess it
wouldn't help much.

> 
> > So I suppose it'd be nice to be able to do something roughly like:
> > 
> > $ git series create kvm/a/main v4.8-rc2
> 
> I do plan to add a second argument to start to provide a base.  Sounds
> like I should also consider providing an alias "create" for "start". :)

Yep, I meant start :-).

> 
> > ...
> > $ git series create mips/a/main v4.8-rc2
> > ...
> > $ git series create kvm/b/main kvm/a/main
> > (Implicitly depends on "kvm/a/main" branch / series)
> > ...
> > $ git series depend add mips/a/main
> > (Adds [sequence of] distinct merges at the beginning of the series)
> > ...
> > $ git series create kvm/c/main kvm/b/main
> > ...
> > $ git series checkout mips/a/main
> > ... hack a bit on that branch
> > $ git series update
> >  It'd probably be necessary to analyse the graph of dependencies to
> >  figure out the order, and for each series regenerate the merges and
> >  rebase on top of them:
> >    checkout dependency 1
> >    merge dependency 2
> >    ...
> >    rebase --onto HEAD <last merge at beginning of current series> series
> > 
> > it'd probably be convenient to be able to autocommit each rebased
> > series too, which I suppose raises the question of conflicts, and how
> > hard it'd be to have --abort-all, --abort, & --continue options.
> > 
> > git series rebase -i should obviously go back to the last merge after
> > the bases, since you can't meaningfully rebase -i merges.
> > 
> > git series rebase onto... perhaps that should require a dependent branch
> > or series that is being replaced (previously implicitly the current
> > base), and I suppose require regenerating the merges too, to avoid
> > storing more metadata.
> > 
> > Sounds like it'd certainly need a fair bit of complexity to do that
> > though, although if number of dependencies was limited to 1 it could be
> > a lot simpler.
> 
> Yeah, I could imagine several possible workflows here, but it would
> definitely increase complexity quite a bit.
> 
> If it would help people with various interdependent maintainer trees,
> I'd definitely consider it, especially if the complexity remains limited
> to people who actually declare series dependencies.
> 
> As an alternative to doing all of that completely automatically, I could
> imagine tracking the dependencies similar to how git tracks upstream
> "tracking" branches, and then providing guided next steps but still
> requiring you to rebase the series individually.  For instance, if
> you have a series 4.7/base, and then another series 4.7/kvm that depends
> on 4.7/base, "git series status" on 4.7/kvm could notice if you've made
> changes in 4.7/base since the version you based 4.7/kvm on, like this:
> 
> $ git series status
> On series 4.7/kvm
> Base series 4.7/base updated (rebased N commits ahead)
>   (use "git series rebase 4.7/base" to update)
> 
> And conversely, "git series status" on 4.7/base could say:
> 
> $ git series status
> On series 4.7/base
> Dependent series 4.7/kvm (and N more) needs update
>   ("git series checkout 4.7/kvm" then "git rebase 4.7/base" to update)
> 
> Would that help simplify the process, to avoid having to carefully
> orchestrate it while watching a repository browser?

I could see that being useful, although personally I'm usually quite
aware of the overall commit graph I'm dealing with, so it might be more
handy for when I forget that some other random WIP branch is based on
it.

I suppose though once you have git-series taking away the need to find
the base commit, its much simpler to script a sequence of rebases in the
right order, so the problem may just fade away. Even redundant rebases
should be harmless (although I just tried one and "Base unchanged" seems
to be treated as an error which necessitates a "git rebase --continue"
after it).

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]