On 07/16/2018 02:57 AM, Russell King - ARM Linux wrote: > On Mon, Jul 16, 2018 at 05:24:08PM +0800, Chen-Yu Tsai wrote: >> On Mon, Jul 16, 2018 at 5:13 PM, Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: >>> >>> >>> On 07/15/2018 03:50 PM, Olof Johansson wrote: >>>> Thanks Stephen, I keep saying every time you catch these that I need >>>> to run the same script. :( >>>> >>>> Florian, I wonder if this happened when you rebased to squash in the fix? >>> >>> Humm, could be, all I did (and it was not the first time) was to do an >>> interactive rebase with --preserve-merges. AFAICT, all of these commits >>> came from Eric's pull request, so what I typically do is just sign off >>> on the merge commit, but do not apply my SoB to all commits coming from >>> that pull request if that makes sense? >> >> When you rebase, if the commit is re-applied, the committer changes to >> you, so you need to add your SoB to all commits you rebased. >> >> I suppose you could override it with GIT_COMMITTER_NAME and >> GIT_COMMITTER_EMAIL environment variables, but that sort of distorts >> the SoB if any changes were added due to rebasing, such as resolution >> of merge conflicts. > > A different point: should *anyone* be rebasing commits that they did not > themselves commit. Discuss. > > IMHO no - the commits were made public, and anyone could pull the tree > from which they came in order to do further work before submitting that. > Rebasing changes the commit IDs, which can lead to duplicate commits > ending up in mainline. With other changes on top, this causes totally > unnecessary conflicts. > Well in that case, I thought it would be cleaner to just squash Arnd's build fix since the commit had not been merged into arm-soc, but I will keep in mind not to do that anymore. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html