9

There is a bug in my code which can be easily reproduced since a test fails.

Up to now I used git-bisect in such cases, but it is only useful if there is only one git repo.

In my case there are 7.

Is there a way to do something like git-bisect but for N git repositories?

Update

There is one "container" Repo this contains mostly config. It is related to a particular customer.

Then there is one repo for the core-application.

Then where are N repos for plugins for this core-application.

Git submodules are not used in this context.

Update2

Up to now I don't use the google repo tool. AFAIK it can't bisect, too.

guettli
  • 25,042
  • 81
  • 346
  • 663
  • 1
    7 repositories? Any reason for this? Doesn't they have anything in common? Can't you make an 8th, and pull all the other 7 into it, combining the history, and then you could run bisect there? – Lasse V. Karlsen Aug 02 '17 at 10:47
  • 1
    How are the seven repositories related? Are some submodules or subtrees of others? Are some libraries? What is preventing you from determining the repository that contains the bug? – ChrisGPT was on strike Aug 02 '17 at 11:00
  • I updated the question an explained why there are several git repos. – guettli Aug 02 '17 at 12:53
  • Assuming that the other repos are submodules, you can easily run `git submodule update` after each `git bisect`, and even script it if you need. – cmbuckley Aug 02 '17 at 12:56
  • Do you have any way of establishing revision correspondence between all your repositories? I.e. for a given revision of the core application, can you tell which revision(s) of the plugins may be used with it? – Leon Aug 07 '17 at 09:20
  • 1
    bisect the dates yourself and use ``git log --before`` and ``--after`` in each repo to find the matching commit for the timestamp you're testing. Checkout the corresponding commits in all repos and check them. Then search for the next date and test again, just like git bisect does for a single repo. – allo Aug 10 '17 at 15:03

1 Answers1

5

  1. First off : find a state when the test passed.

  2. Then : check if the test passes when reverting one single of the 7 repositories

For example, let's say that :

  • the test passed when repositories were at commits :

    A1 A2 A3 A4 A5 A6 A7

  • the test doesn't pass when all repositories are at their new HEAD :

    B1 B2 B3 B4 B5 B6 B7

try to see if the test passes in the following configurations :

A1 B2 B3 B4 B5 B6 B7   
B1 A2 B3 B4 B5 B6 B7   
B1 B2 A3 B4 B5 B6 B7   
etc ...

If you manage to isolate a single repo this way : you just have to bisect on that one.

LeGEC
  • 46,477
  • 5
  • 57
  • 104