Message ID | 20210907213943.GA822380@bjorn-Precision-5520 (mailing list archive) |
---|---|
State | Not Applicable, archived |
Delegated to: | Bjorn Helgaas |
Headers | show |
Series | [GIT,PULL] PCI changes for v5.15 | expand |
On Tue, Sep 7, 2021 at 2:39 PM Bjorn Helgaas <helgaas@kernel.org> wrote: > > drivers/net/ethernet/broadcom/bnxt/bnxt.c > drivers/net/ethernet/broadcom/bnx2.c > Fallout from the VPD changes below. These include both PCI core and > driver changes, and the driver changes got merged via the net tree and > then reverted so everything would be merged via the PCI tree. Christ. So the revert from the networking tree has basically _zero_ useful information. It just says "revert". David, that's not ok. The natural reaction to this situation is "ok, this commit was done both in the networking tree and the PCI tree, but then the networking tree reverted it. So there must be something wrong with it, and I should take the reverted state" but Bjorn's comment implies that it was reverted in order to _avoid_ merge conflicts since it was also done in the PCI tree, which is pure and utter garbage, because I end up with the merge conflict *ANYWAY* due to the other changes, and now instead of going "ok, the PCI tree had that same commit, all good", I have to go "ok, so the PCI tree had the same commit, but it was reverted in the networking tree, so now I have both sides making different changes and a very confusing merge". Here's the thing. There's a couple of very simple and basic rules: (a) don't do stupid things. In particular, don't try to make my merges easier by adding MORE crap on top of the known merge problem. This is not that different from "don't rebase merge conflicts away". You're making things worse. (b) INDEPENDENTLY of that "don't do stupid things", the #1 rules for _any_ commit is to give the damn reason for the commit. You can't just say "revert X" in a commit message. That's not a reason. That doesn't explain ANYTHING at all. So now I have to basically guess at what is going on. Yes, yes, I can make fairly informed guesses from looking more carefully at the code, looking at the *other* commit messages, and doing something sensible. So my guesses aren't going to be about tossing a coin. But please don't do these kinds of things! Don't make my life "easier" by doing stupid things, and DO put a reason for every single commit you do. Reverts aren't "oh, I'm just turning back the clock, so no reason to say anything else". Linus
The pull request you sent on Tue, 7 Sep 2021 16:39:43 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v5.15-changes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ac08b1c68d1b1ed3cebb218fc3ea2c07484eb07d
Thank you!
On Tue, Sep 07, 2021 at 07:08:42PM -0700, Linus Torvalds wrote: > On Tue, Sep 7, 2021 at 2:39 PM Bjorn Helgaas <helgaas@kernel.org> wrote: > > > > drivers/net/ethernet/broadcom/bnxt/bnxt.c > > drivers/net/ethernet/broadcom/bnx2.c > > Fallout from the VPD changes below. These include both PCI core and > > driver changes, and the driver changes got merged via the net tree and > > then reverted so everything would be merged via the PCI tree. > > Christ. > > So the revert from the networking tree has basically _zero_ useful > information. It just says "revert". Sorry about that. I intended to push my test merge in case you wanted to see my resolution, but I forgot. I just pushed it ("v5.15-merge"), but I'm guessing you've already come up with the same resolution. I was a little mystified about why there was a conflict at all, since I expected those patches to apply cleanly on top of the revert, and I should have investigated that more instead of just chalking it up to my lack of git-fu. Bjorn
On Tue, Sep 7, 2021 at 7:26 PM Bjorn Helgaas <helgaas@kernel.org> wrote: > > I was a little mystified about why there was a conflict at all, since > I expected those patches to apply cleanly on top of the revert, and I > should have investigated that more instead of just chalking it up to > my lack of git-fu. It's because that wasn't the only change to that function. So for example, the networking tree had that "bnx2: Search VPD with pci_vpd_find_ro_info_keyword()" commit, and then reverted it. Fine - that's a no-op, right? So then the fact that the PCI tree had that change - and other changes - should just merge cleanly. Except the networking tree *also* had "bnx2: Replace open-coded version with swab32s()", and that wasn't reverted. End result: the networkling tree and the PCI tree touched the exact same code, and did it differently. So - conflict. And the bnxt.c case is similar, except there the networking tree _did_ revert the "other" commit too, but it seems to have actively done something else as well. See how the networking tree actually has that "This reverts commit 58a9b5d2621e725526a63847ae77b3a4c2c2bf93" _twice_, because it did it wrong. Anyway, because of that "revert twice", my tree actually had (before your pull) that i = pci_vpd_find_tag(vpd_data, vpd_size, PCI_VPD_LRDT_RO_DATA); if (i < 0) { netdev_err(bp->dev, "VPD READ-Only not found\n"); goto exit; } code duplicated twice, so now the conflict was due to that. And the thing is, the revert for some merge reason is always the wrong thing to do, but it's doubly wrong when it's done badly. I'd *much* rather see a few more conflicts, and then go "oh, tree X and Y both did Z, but Y also did ABC". That's a very straightforward conflict, and I can go "I'll take the Y side" because it's clearly and unambiguously the "superset" of the changes. The revert actually made things harder. Now neither branch had a superset of changes, and the networking side in particular looked like the original change had actually been in error, and should be reverted entirely (and the PCI side had just missed the problem). See? It actually technically looked like the networking tree did more, and knew more. A revert is additional work, and by default I assume that a revert was done for a sane reason (ie "that commit was broken, so I'll revert it"). In this case I had to take the hint from your pull request that it wasn't that the commit was broken and thus reverted. So the networking tree did two really horribly bad things: doing extra work for a bad reason, and then not even *documenting* that bad reason. Either of them is bad on its own. Together, they are really really bad. Anyway. I obviously _think_ my merge is all good (and it wasn't really a complicated merge despite the annoyance), but considering the confusion, it's always a good idea to double-check. Because mistakes do happen. I'm pretty good at merges these days, but they most definitely happen to me too. Linus