[Ksummit-2012-discuss] [ATTEND] stable-kernel git management?

James Bottomley James.Bottomley at HansenPartnership.com
Wed Jun 20 16:37:03 UTC 2012

On Wed, 2012-06-20 at 09:24 -0700, Greg KH wrote:
> On Wed, Jun 20, 2012 at 06:04:22PM +0200, Takashi Iwai wrote:
> > > Problem is, it would be constantly rebased, which I don't want to do,
> > > and it would be thrown away after each stable release as well, when I do
> > > a real release, which would take a whole lot of explaining to users as
> > > to how to handle it.
> > 
> > It'd just look like linux-next, no?
> Not that I can determine.
> > And I don't know why it must be so often rebased.  Aren't stable
> > patches rather accumulative?
> I often (i.e. at least once a release), need to pull a patch out of the
> middle of the series and throw it away.
> > If a patch has to be removed, it can be a simple git-revert.  The
> > revert is also a good information so that someone won't stumble on the
> > same commit.
> That's why I keep the patches in a quilt tree, not a git tree, as
> accumulating the reverts and other fixes can be a pain in the long-run.
> quilt works much better for this.

Just on this point, since I use git mostly in place of quilt now.
'quilt delete' can be exactly done by 'git rebase --onto sha^ sha' where
sha is that sha1 id of the patch you're destroying.  As greg alluded to,
this causes a rebase of all patches above sha.


More information about the Ksummit-2012-discuss mailing list