Hi Shourya, On Mon, Apr 27, 2020 at 12:49:20PM +0530, Shourya Shukla wrote: > On 20/04 04:19, Denton Liu wrote: > > > 1. The patch fails test #2 in t7420, i.e., the test to verify the working of 'set-url' > > > subcommand. > > > > The 'set-url' command implicitly runs sync once it is changed. I would > > go further than what Christian suggests and just call sync_submodule() > > (in C) at the end of module_set_url(). > > I have implemented this, yet running the test still gives an error. The > function 'init_pathspec_item' in 'pathspec.c' tends to fail. Going > further deep, the function 'prefix_path_gently' fails. I think this is > happening because of the relative path outside the superproject for > '../newsubmodule' and hence it throws a problem with prefixing. I can't think of a reason why Git should be trying to do anything with the path `../newsubmodule`. The set-url part should only write that string into the `.gitmodules` and the sync part should only write into `.git/config`. Neither of these steps should actually access the submodule repo in any way. > The exact function responsible here is 'normalize_path_copy' in > 'path.c'. > > On doing '-i -v' while running the test. The problem comes down to: > > fatal: ../newsubmodule: '../newsubmodule' is outside repository at '<path>/git/t/trash directory.t7420-submodule-set-url/super' Perhaps it's failing at the `git submodule update --remote` part? It's hard to tell without more information. One thing you can do is try running the test with `-x` which would enable shell tracing. This gives even more information on the test that's running, including exactly which command is failing. > What exactly is wrong here and how should this problem > and similar ones (if encountered) be approached? Do we follow > certain procedures when debugging problems at such an intricate level? I can't tell exactly what's wrong from the information you've provided. Do you have link to the code you're working on? Alternatively, it might be a good idea to post a RFC patch onto this list for wider discussion. Some general debugging techniques that I've found helpful include * debug prints using fprintf(stderr, ...) * `-x` for test scripts (as mentioned above) * `debug` in test scripts (which launches GDB) * using `GIT_DEBUGGER=1 ./bin-wrappers/git <subcommand>` (which also launches GDB) although I'm not quite sure how applicable they are to your case. Maybe it would be helpful for you to grab a stack trace of where the die() is being called in GDB to understand the cause of the problem? -Denton > Regards, > Shourya Shukla
