Message ID | 20221212134425.b20b80955e5e8a4a36ce1b9a@linux-foundation.org (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [GIT,PULL] non-MM commits for 6.2-rc1 | expand |
On Mon, Dec 12, 2022 at 01:44:25PM -0800, Andrew Morton wrote:
> wifi: rt2x00: use explicitly signed or unsigned types
Why is this part of your PULL? This was a netdev/wireless tree fix which
was in 6.1-rc5. Kalle wrote that he took it on 21 Oct 2022 in:
https://lore.kernel.org/all/166633563389.6242.13987912613257140089.kvalo@kernel.org/
Jason
On Mon, 12 Dec 2022 15:16:43 -0700 "Jason A. Donenfeld" <Jason@zx2c4.com> wrote: > On Mon, Dec 12, 2022 at 01:44:25PM -0800, Andrew Morton wrote: > > wifi: rt2x00: use explicitly signed or unsigned types > > Why is this part of your PULL? This was a netdev/wireless tree fix which > was in 6.1-rc5. Kalle wrote that he took it on 21 Oct 2022 in: > https://lore.kernel.org/all/166633563389.6242.13987912613257140089.kvalo@kernel.org/ > Huh. I guess git quietly accepts the identical commit, so Stephen never told me and my test-merge-with-Linus-latest also came up clean. Which leaves it to me to manually handle these things, and that's unreliable. Is there some way of telling git to complain about identical changes when doing a trial merge?
On 12/12/22 23:27, Andrew Morton wrote: > On Mon, 12 Dec 2022 15:16:43 -0700 "Jason A. Donenfeld" <Jason@zx2c4.com> wrote: > >> On Mon, Dec 12, 2022 at 01:44:25PM -0800, Andrew Morton wrote: >> > wifi: rt2x00: use explicitly signed or unsigned types >> >> Why is this part of your PULL? This was a netdev/wireless tree fix which >> was in 6.1-rc5. Kalle wrote that he took it on 21 Oct 2022 in: >> https://lore.kernel.org/all/166633563389.6242.13987912613257140089.kvalo@kernel.org/ >> > > Huh. I guess git quietly accepts the identical commit, so Stephen > never told me and my test-merge-with-Linus-latest also came up clean. > Which leaves it to me to manually handle these things, and that's > unreliable. > > Is there some way of telling git to complain about identical changes > when doing a trial merge? Probably not exactly that, but there seems to be a way with "git cherry". Dunno how reliable in practice, seems to be based on patch-id so probably can fail easily if the commit or context changes slightly? $ git checkout mm-nonmm-stable-2022-12-12 $ git cherry -v origin/master + eabb7f1ace53e127309407b2b5e74e8199e85270 lib/debugobjects: fix stat count and optimize debug_objects_mem_init + 461cc6e54ececa86007d44b0ff2521f75b872745 arc: ptrace: user_regset_copyin_ignore() always returns 0 ... + d472cf797c4e268613dbce5ec9b95d0bcae19ecb debugfs: fix error when writing negative value to atomic_t debugfs file - d04bb0852b8bd31c53981a04ff0132698d24523d wifi: rt2x00: use explicitly signed or unsigned types + 3965292ad0ca70320f1c632f2ac3b886c88b9e80 checkpatch: add check for array allocator family argument order ... Seems to have worked in this case and flagged the wifi commit with '-' HTH, Vlastimil
On Mon, Dec 12, 2022 at 2:27 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > Is there some way of telling git to complain about identical changes > when doing a trial merge? No, the merge functionality of git literally doesn't care about individual commits. (git does walk the commit chain as part of finding the common ancestor, but apart from that, very fundamentally merging in git is *not* about merging individual commits at any point. None of the darcs "patch algebra" nonsense). But as Vlastimil pointed out, git does have various log-based models for finding identical patches based on the patch ID. Those are intentionally not used for merging, but for the various "move patches around" models (cherry-picking and rebasing). Linus
On Mon, Dec 12, 2022 at 1:44 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > - A series from Yang Yingliang to address rapido memory leaks "rapido memory leaks"? [ Goes off to look at the commits ] Ahh. Typo. Linus
The pull request you sent on Mon, 12 Dec 2022 13:44:25 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm tags/mm-nonmm-stable-2022-12-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8702f2c611bf124c48b21b5c57bfc156cd11f4ca
Thank you!
On Tue, 13 Dec 2022 00:16:07 +0100 Vlastimil Babka <vbabka@suse.cz> wrote: > On 12/12/22 23:27, Andrew Morton wrote: > > On Mon, 12 Dec 2022 15:16:43 -0700 "Jason A. Donenfeld" <Jason@zx2c4.com> wrote: > > > >> On Mon, Dec 12, 2022 at 01:44:25PM -0800, Andrew Morton wrote: > >> > wifi: rt2x00: use explicitly signed or unsigned types > >> > >> Why is this part of your PULL? This was a netdev/wireless tree fix which > >> was in 6.1-rc5. Kalle wrote that he took it on 21 Oct 2022 in: > >> https://lore.kernel.org/all/166633563389.6242.13987912613257140089.kvalo@kernel.org/ > >> > > > > Huh. I guess git quietly accepts the identical commit, so Stephen > > never told me and my test-merge-with-Linus-latest also came up clean. > > Which leaves it to me to manually handle these things, and that's > > unreliable. > > > > Is there some way of telling git to complain about identical changes > > when doing a trial merge? > > Probably not exactly that, but there seems to be a way with "git cherry". Dunno > how reliable in practice, seems to be based on patch-id so probably can fail > easily if the commit or context changes slightly? Well here's a hacky thing - just look for duplicated patch titles after stripping away the hashes. $ git log --oneline --no-merges v6.0..HEAD | sed -e "s/[^ ]* //" | sort > /tmp/1 $ uniq < /tmp/1 > /tmp/2 $ diff -u /tmp/1 /tmp/2 | grep "^-.*" The above turns up 67 duplicates in Linus's tree and 382 in linux-next. Maybe this is wrong - I'm just tossing it out there in the hope that someone will do the work for me :)
On Mon, Dec 12, 2022 at 6:35 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > Well here's a hacky thing - just look for duplicated patch titles after > stripping away the hashes. Please don't do that. Just use the git machinery that Vlastimil pointed at. "git cherry" uses the actual patch ID (which is just a hash of the patch with whitespace removed), so it actually looks at the patch itself, not just eh first line of the commit message. If you insist on writing your own shell script for this, please use that same "patch-id" logic. That's made available by "git patch-id". But do "man git-cherry" and "man git-patch-id" before you do any of that. And in no situation should you go "the first line of the commit message is identical, so the patches must be the same". Linus
Hi Andrew, On Mon, 12 Dec 2022 18:35:54 -0800 Andrew Morton <akpm@linux-foundation.org> wrote: > > On Tue, 13 Dec 2022 00:16:07 +0100 Vlastimil Babka <vbabka@suse.cz> wrote: > > > On 12/12/22 23:27, Andrew Morton wrote: > > > On Mon, 12 Dec 2022 15:16:43 -0700 "Jason A. Donenfeld" <Jason@zx2c4.com> wrote: > > > > > >> On Mon, Dec 12, 2022 at 01:44:25PM -0800, Andrew Morton wrote: > > >> > wifi: rt2x00: use explicitly signed or unsigned types > > >> > > >> Why is this part of your PULL? This was a netdev/wireless tree fix which > > >> was in 6.1-rc5. Kalle wrote that he took it on 21 Oct 2022 in: > > >> https://lore.kernel.org/all/166633563389.6242.13987912613257140089.kvalo@kernel.org/ > > >> > > > > > > Huh. I guess git quietly accepts the identical commit, so Stephen > > > never told me and my test-merge-with-Linus-latest also came up clean. > > > Which leaves it to me to manually handle these things, and that's > > > unreliable. > > > > > > Is there some way of telling git to complain about identical changes > > > when doing a trial merge? > > > > Probably not exactly that, but there seems to be a way with "git cherry". Dunno > > how reliable in practice, seems to be based on patch-id so probably can fail > > easily if the commit or context changes slightly? > > Well here's a hacky thing - just look for duplicated patch titles after > stripping away the hashes. > > > $ git log --oneline --no-merges v6.0..HEAD | sed -e "s/[^ ]* //" | sort > /tmp/1 > $ uniq < /tmp/1 > /tmp/2 > $ diff -u /tmp/1 /tmp/2 | grep "^-.*" > > The above turns up 67 duplicates in Linus's tree and 382 in linux-next. > Maybe this is wrong - I'm just tossing it out there in the hope that > someone will do the work for me :) I already do this when I produce my stats after the merge window - I produce three lines like these (from last time): Commits with the same SHA1: 10436 Commits with the same patch_id: 342 Commits with the same subject line: 20 The above is pretty easy, but takes a while (looking at 11000+ commits) because I am just conparing Linus' tree to one of my trees (so 2 branches in my tree). During out development phase, these commits could be spread over 350+ branches in my tree :-( I will have a play and see what I can come up with. The plan would be to figure these out when I fetch trees and only report them to people who care (just you, Andrew, initially) as there are trees out there for which duplicating patches between the development branches and -fixes branches (and Linus' tree) is part of the process :-(