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] [day] [month] [year] [list]
Date:	Wed, 23 Mar 2011 11:10:42 -0700
From:	David Brown <davidb@...eaurora.org>
To:	Daniel Walker <dwalker@...o99.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Bryan Huntsman <bryanh@...eaurora.org>
Subject: Re: [Git pull] MSM for v2.6.39

On Wed, Mar 23 2011, Daniel Walker wrote:

> On Thu, 2011-03-17 at 08:59 -0700, David Brown wrote:
>> David Brown (16):
>>       msm: Add CPU queries
>>       msm: Generalize timer register mappings
>>       msm: Generalize QGIC registers
>>       msm: Add MSM 8960 cpu_is check
>>       Merge branch 'msm-uart' into for-next
>>       Merge branch 'msm-8960' into for-next
>>       Merge branch 'msm-sdcc' into for-next
>>       Merge branch 'msm-fb' into for-next
>>       Merge branch 'msm-8960' into msm-core
>>       msm: Remove broken register definition from trout
>>       msm: Warning fix in trout gpio board file
>>       Merge branch 'msm-core' into for-next
>>       Merge branch 'msm-core' into for-next
>>       Merge branch 'msm-core' into for-next
>>       msm: Use explicit GPLv2 licenses
>>       Merge remote branch 'rmk/for-linus' into for-linus 
>
> Could you change the "for-next" name to something more interesting like
> msm-for-linus .. I think it would be acceptable to just create
> msm-for-linus during the merge window and merge all the sub-tree's into
> that.

I think the problem was that these trees came in, intended for
linux-next, and were pulled into that branch.  Then, I published that as
the tree for the pull-request 'for-linus', but nothing was actually
merged into that tree.

I can do a separate merge into the 'for-linus' tree before the merge
window, but then I won't be giving a pull request for the same commit as
what has been being tested in linux-next.  I'm not sure what is
preferred here.  Doing a separate merge at the end has the benefit of
reducing the number of intermediate merges.  The tree sha will be the
same in either case, so it's really a matter what the history should
look like.

Thanks,
David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ