Re: [lm-sensors] [RFC PATCH] hwmon: (max6650) Convert to be a platform driver

[Lee Jones <lee.jones@linaro.org>]

On Fri, 14 Feb 2014, Laszlo Papp wrote:

> On Fri, Feb 14, 2014 at 9:02 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> >> http://comments.gmane.org/gmane.linux.kernel/1645251
> >> >>
> >> >> Step 2 did not happen. I did not get any review for my change. I
> >> >> literally submitted that within a couple of hours after the request.
> >> >>
> >> >> Could you please tell me what was wrong with that change, and why I
> >> >> did not get any respect not to "xargs rm -rf" my work in that area? I
> >> >> believe I was ignored instead of improving the change, and someone
> >> >> else tried to address the same thing. There was no argument in that
> >> >> thread. It was a technical change. I personally do not feel happy
> >> >> about it.
> >> >
> >> > Let's start again.
> >> >
> >> > Rebase your work on top of the HWMON tree on kernel.org and resubmit
> >> > the entire set. If rebasing takes you more than 20 mins, you're
> >> > probably doing it wrong.
> >>
> >> I tried, but I could not manage it within 20 minutes, so I guess I am
> >> doing something wrong. Can you please provide some pointers how not to
> >> do it wrong? Perhaps, I am not aware of some tricks.
> >
> > One question, are you still working on this stuff or not? I'm confused
> > by the disparity in your messages. I'm going to guess that you're in
> > for now.
> >
> > Do:
> >   `git rebase -i <base> --onto <newbase>`
> > Where:
> >   <base> is the SHA1 of the first patch below your changes in `git log`
> >   <new_base> is Guenter's staging tree on kernel.org
> >
> > Ensure you're rebasing all of your patches (and patches that aren't
> > yours) when your $EDITOR pops up. If they are wrong, delete all the
> > lines in the file and the rebase will be aborted. If they're correct
> > save and close your $EDITOR.
> >
> > You'll receive conflicts. You can see the state of the conflicts using
> > `git status` Open the file, find the conflict markers and make a choice
> > from the HEAD section or the section from your patch. Sometimes
> > you'll need to manually merge the two, if there are changes from both
> > refs that you want to keep. Once you're happy `git commit -a` and `git
> > rebase --continue`. Each conflict should not take you long, but if it
> > does, keep at it, as it's good practice. After a time of doing it,
> > you'll be able to fix merge conflicts in no time at all.
> 
> Right, that is what I have been following myself for a couple of
> years.

> Why it took me more time because I had to go through his
> changes and to understand all in details to make reasonably good
> decisions what to keep and what to drop at the conflicts.

Correct, that's what will improve with time.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog