Re: [PATCH v1 1/3] device property: Implement device_is_big_endian()

Andy Shevchenko
2023-12-18T13:40:40Z

On Mon, Dec 18, 2023 at 01:38:18PM +0100, Bartosz Golaszewski wrote:
> On Mon, Dec 18, 2023 at 12:18 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Mon, Dec 18, 2023 at 12:05:54PM +0100, Bartosz Golaszewski wrote:
> > > On Mon, Dec 18, 2023 at 11:56 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Mon, Dec 18, 2023 at 11:35:04AM +0100, Bartosz Golaszewski wrote:
> > > > > On Fri, Dec 15, 2023 at 4:11 PM Andy Shevchenko
> > > > > <andriy.shevchenko@linux.intel.com> wrote:

...

> > > > > Ugh, this is rebased on top of 6.7-rc3...
> > > > >
> > > > > My tree is based on rc1, if I pull it, then it'll be a mess.
> > > >
> > > > But v6.7-rc3 is something that is already in the upstream.
> > > > I don't see how it can be more "mess" with this. Whatever...
> > >
> > > My for-next branch is based on v6.7-rc1 (as it should IIUC) and if I
> > > now pull Greg's tag, I will be sending rc1-rc3 stuff to Linus Torvalds
> > > in addition to the GPIO changes for v6.8. I bet he will not appreciate
> > > it.
> >
> > No, you will not be sending him -rc1-rc3 stuff at all, that's not how
> > git works.
> >
> > Try it yourself and see. Git does a "what's the changesets that are
> > in this pull request and not already in mine" when determining this.
> > You can see it when doing a 'git request-pull', it will only show you
> > the diff of what will be sent.
> >
> > Also look at the 'git merge-base' output, it will show the point where
> > things will start to be sent, and that will not have all of the -rc1
> > through -rc3 changes in it.
> >
> > > Greg: Is it too late to have this rebased on top of v6.7-rc1 instead?
> >
> > Sorry, but yes. But don't worry, again, git can handle all of this
> > easily! Try it locally and see. Don't fear the 'fast-forward' :)
>
> Sorry for the noise. I did try it locally and noticed that a bunch of
> commits that were merged before rc3 moved "before it" in git log and
> figured this is what the PR would look like. However the PR is correct
> and I should have generated it before sending the email.

Right.

What Linus can rant on is when one rebases his stuff on newer rcX,
the merges on contrary are pretty much okay as long as they are
justified.

> Thanks for a lesson in git.

--
With Best Regards,
Andy Shevchenko