1

I'm trying to update a patch made in tag xilinx-v2017.4 in linux-xlnx to the tag xilinx-v2022.1. In the new version, a function used is no longer available, xilinx_cdma_prep_sg in drivers/dma/xilinx.

I wanted to find out why it was removed, alternatives, etc, so I needed the commit that removed it, so I decided to try git bisect using grep -Hrin xilinx_cdma_prep_sg drivers/dma/ for testing:

git checkout xilinx-v2022.1
grep -Hrin  xilinx_cdma_prep_sg drivers/dma/ # Function is NOT available
git bisect start
git bisect bad # Since function is NOT available here
git checkout xilinx-v2017.4
grep -Hrin  xilinx_cdma_prep_sg drivers/dma/ # Function is available
git bisect good # Since function is available here

git bisect proceeds apparently normally, however, it never once shows a good commit for evaluation, and at the end, it shows me a completely unrelated commit(1e8a655db2f4dd8777eda08c2af7d1381b9eecca , no mention to the function I'm interested under git show).

What is going on? This might be a duplicate of some other question, but I don't know what to search for, I have no idea what's going on.

I have tried with other commits, including the one returned by git merge-base xilinx-v2017.4 xilinx-v2022.1, but I always get different, wrong results.

I checked this question, but I'm not sure it applies here, and it didn't contain a reproducible example, so I think this question should be useful even if it's a duplicate.

Arthur Moraes Do Lago
  • 355
  • 1
  • 9
  • 1
    Could you try [`git log -Gxilinx_cdma_prep_sg`](https://git-scm.com/docs/git-log#Documentation/git-log.txt--Gltregexgt) instead of `git bisect`? – phd Nov 29 '22 at 18:45
  • 2
    Depending on the history of the repo, `tag1..tag2` may contain commits from side branches, and lead `git bisect` to inspect unrelated commits. Try comparing `git log --boundaries --oneline --graph tag1..tag2` and same command with `--ancestry-path`. Once you have an idea of what the history looks like, add the `-G` option suggested by phd. – LeGEC Nov 29 '22 at 19:36
  • git log -G could be useful so I can continue my task, but I would still would like to understand why bisect fails. But, while testing -G, I found even weirder results, I only get 3 commits, 1 stops referencing said function, and 2 others are duplicates adding said function to the code base. There are no commits removing the function declaration(so where the is it????). – Arthur Moraes Do Lago Nov 29 '22 at 20:48
  • I don't mind bisect inspecting unrelated commits, so long that in the end, it gives me the correct result(I don't mind waiting for it to go through tens of thousands of commits, it ammounts to ~17 tests in the anyway). I tought I had isolated any issues with ancestry, etc, by using `merge-base`, but I will try to understand their relationship better, but I don't think I can analyze 5 years of commits in the linux kernel. – Arthur Moraes Do Lago Nov 29 '22 at 20:50
  • Can you show results of *your* `git log -G` (I'm too lazy to clone the whole repo now for single command)? – Lazy Badger Nov 30 '22 at 01:24
  • 1
    If stuff was dropped in merges, `git log` might not find it by default. You'll need `--full-history` and/or `-m` options. The bisection failure is more interesting, but might be occurring because it's all commits immediately "after" (in topo order) the "good" one that drop the code. – torek Nov 30 '22 at 01:55
  • This is a way to run bisect faster (no need to checkout, use `git grep `): `git bisect start --no-checkout master xilinx-v2017.4 && git bisect run git grep -Fq xilinx_cdma_prep_sg BISECT_HEAD && git bisect reset` I got the same commit `1e8a655db2f4dd8777eda08c2af7d1381b9eecca` though. – phd Nov 30 '22 at 16:16
  • `git log -Gxilinx_cdma_prep_sg --full-history -m -p xilinx-v2017.4..xilinx-v2022.1 -- drivers/dma/xilinx/xilinx_dma.c` found merge commit `8a0be21c42a2`. To view it with its full patch: `git show -m 8a0be21c42a2` – phd Nov 30 '22 at 23:07
  • Thank you, these commands are helping me a lot to understand the current scenario. However, 8a0be21 is a merge commit. Since we are using `git log --full-history`, and the modification I'm looking for was not apparently not introduced exclusively during the merge, shouldn't git log have also shown me a commit that makes the change besides the one that merges?(something that precedes e0d688d?). This doesn't seem to be the case. I'll update the question soon with the list of what I got and some extra info I'm looking into. – Arthur Moraes Do Lago Dec 01 '22 at 20:09

0 Answers0