CC'ing kernel newbies for anyone else trying to learn how linux-next
works.
On Fri, Jul 06, 2018 at 11:49:51AM -0400, Steven Rostedt wrote:
> On Fri, 6 Jul 2018 23:42:13 +0900
> Sergey Senozhatsky <sergey.senozhatsky@xxxxxxxxx> wrote:
>
> > On (07/06/18 15:47), Arnd Bergmann wrote:
> > [..]
> > > Fixes: bfe80ed3d7c7 ("vsprintf: add command line option debug_boot_weak_hash")
> >
> > Seems like this one is still in linux-next.
> > Can we squash this patch and bfe80ed3d7c7?
> >
>
> I prefer not to do squashes unless absolutely necessary. Yes, it is in
> next, but even branches pulled into next should try to resist rebasing
> (I never rebase my next branch unless there is a real bug that will
> break bisecting).
Steve if you do not rebase your next branch and the branch ends up
containing fixes to patches like the above doesn't this mean that when
you do a pull request to Linus the branch you are asking to be pulled
will be too 'dirty' i.e. I thought that the pull request should be like
a patch set and only contain the 'final product' not every change that
was made during development?
I was under the impression that each maintainer constantly rebased their
next branches and that was why one has to checkout the tagged linux-next
each day instead of just pulling. From information on the net somewhere
I have been checking out linux-next using this shell function
checkout-next () {
local branch='linux-next'
git checkout master
git remote update linux-next
git branch -D $branch
git checkout -b $branch $(git tag -l "next-*" | tail -1)
}
Also, when my leaks tree got included in linux-next I was told that it
was ok to rebase and have since been rebasing mercilessly.
thanks in advance for your time,
Tobin.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
