Messages in this thread |  | | Date | Fri, 14 Feb 2014 10:17:25 +0000 | From | Lee Jones <> | Subject | Re: [lm-sensors] [RFC PATCH] hwmon: (max6650) Convert to be a platform driver |
| |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |