On Mon, Oct 24, 2022 at 10:42 PM Juergen Gross <jgross@xxxxxxxx> wrote:
>
> I'm seeing a strange inconsistency in torvalds/linux.git:
Not really an inconsistency, just an artifact of how git works.
Admittedly surprising once you internalize what's going on.
But you have most definitely found a merge mistake of mine, which is
why you see that behavior.
Let me explain:
> Commit e0e0747de0ea3dd can be found in "git log" output,
Right, the commit is very much there, as you can see when you just do
a full "git log" and look for it. No question about that.
So then the question becomes "why don't I see it when I do xyz":
> but according to the source it is not applied. It isn't found either when looking at
> "git log drivers/scsi/mpt3sas/mpt3sas_base.c", in spite of this being
> the source modified by said patch.
So this is a pretty fundamental git thing: when you do something like
git log drivers/scsi/mpt3sas/mpt3sas_base.c
what you are actually telling git is "show my the _simplified_ history
as it pertains to that path".
That's basically how all the git log commands work - it always starts
out with the *full* history, but then you can simplify that history
different ways.
Those simplifications range from the trivial, like using --grep to
only show commits that match a certain pattern, or being based on
dates, or obviously commit ranges.
And one of the more subtle one is very much using a pathname limiter
to only show commits that are relevant for a certain directories or
pathnames.
And it's subtle because that simplification is *very* aggressive, and
will literally prune away any history that is not relevant to that
pathname.
And it turns out that in the current -git tree, commit e0e0747de0ea3dd
is indeed no longer relevant to the history of that file, and as a
result gets simplified away.
Now the "Why?" is the meat of it.
Here's the details:
- I merged that fix Sept 22 in commit bf682942cd26 ("Merge tag
'scsi-fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi")
so when you do git log of *that* state, using
git log bf682942cd26 drivers/scsi/mpt3sas/mpt3sas_base.c
you can see that commit in the log, and you can also see the effect of
it in that tree if you do something like
git show bf682942cd26:drivers/scsi/mpt3sas/mpt3sas_base.c
but as you go through the history, you 'll have seen that
- my next SCSI merge is Oct 7, commit 62e6e5940c0c ("Merge tag
'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi")
and if you then for *that* commit do that
git log 62e6e5940c0c drivers/scsi/mpt3sas/mpt3sas_base.c
the commit you were looking for is no longer there!
Why?
It's because through that pull, I got commit 9df650963bf6 ("scsi:
mpt3sas: Don't change DMA mask while reallocating pools"), and it
conflicts with the other fix.
And I mis-merged that conflict, taking the new version of the file
entirely from the new SCSI pull. As a resulkt, when you look at my
merge, you don't see any conflict at all, because my merge was
basically "take the version from the SCSI tree".
Which was obviously wrong. The merge resolution *should* have looked
something like this:
- if (ioc->is_mcpu_endpoint ||
- sizeof(dma_addr_t) == 4 || ioc->use_32bit_dma ||
- dma_get_required_mask(&pdev->dev) <= DMA_BIT_MASK(32))
+ if (ioc->is_mcpu_endpoint || sizeof(dma_addr_t) == 4 ||
- dma_get_required_mask(&pdev->dev) <= 32) {
++ dma_get_required_mask(&pdev->dev) <= DMA_BIT_MASK(32)) {
ioc->dma_mask = 32;
but I messed up, and took the version directly from the SCSI tree, not
realizing that the *new* SCSI pull didn't have the *old* fix that I
had already gotten two weeks earlier.
So this then had two effects:
(a) the tree obviously lost the one-liner fix
(b) git now sees that all the contents for that file comes entirely
from that side of the SCSI merge, which is why it simplified away all
those other commits that had no effect on the end result.
So this is not a git inconsistency, it's just a merge error on my part.
Thanks for noticing, and I'll also Cc this reply to the linux-scsi
mailing list so that I can link to this longer explanation in my fix
commit message.
Linus
