Re: [RFC][PATCH 0/2] submodule: port 'set-url' from shell to C

From: Denton Liu <liu.denton@gmail.com>
Date: Apr 27, 2020, 10:17 UTC
Message-ID: <20200427101720.GA649724@generichostname>
In-Reply-To: <20200427071920.GA23846@konoha>

Hi Shourya,

On Mon, Apr 27, 2020 at 12:49:20PM +0530, Shourya Shukla wrote:

Show 13 quoted lines

> 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.

Show 6 quoted lines

> 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