On Fri, 14 Feb 2014, Laszlo Papp wrote: > On Fri, Feb 14, 2014 at 9:02 AM, Lee Jones <lee.jones@xxxxxxxxxx> 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 _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
