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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 Feb 2014 09:02:17 +0000
From:	Lee Jones <lee.jones@...aro.org>
To:	Laszlo Papp <lpapp@....org>
Cc:	Jean Delvare <jdelvare@...e.de>,
	LKML <linux-kernel@...r.kernel.org>, lm-sensors@...sensors.org,
	Guenter Roeck <linux@...ck-us.net>
Subject: Re: [lm-sensors] [RFC PATCH] hwmon: (max6650) Convert to be a
 platform driver

> >> 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.

-- 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/