Re: [Outreachy] Introduction
Hi Sangeeta
On 15/10/2020 14:57, Sangeeta NB wrote:
Show 14 quoted lines
> On Thu, Oct 15, 2020 at 7:09 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
> Hey Phillip,
>
>> As we store the config options in default_diff_options and then copy
>> them across at the beginning of repo_setup_diff() we can use a flag in
>> struct diff_options which is set by handle_ignore_submodule_arg() to
>> tell if we need to initialize opts->flags.ignore_untracked_in_submodules
>> in repo_setup_diff()
>
> Even if we don't set a global flag it is working fine because we are
> setting the default first, and would let the config override it. I
> have updated the code in the PR and you can have a look at it. I have
> also added --ignore-submodules=none in some tests to get the results
> mentioned earlier.
Thanks, I'll have a look later
Show 11 quoted lines
>> Are you adding the printf and then running t3600? If so then the extra
>> line of output breaks a lot of tests which in turn breaks to setup for
>> the test that was failing so there are uncommitted changes.
>> Unfortunately it is hard to run a subset of tests in a lot the test
>> scripts as there are implicit dependencies between the individual tests
>> them.
>>
> Oh, okay it makes sense.
>
>>
>> I'm afraid I'm still no closer to figuring out why that test in t3600 fails
diff --git a/submodule.c b/submodule.c
index 8f6227c993..c4182be633 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1679,6 +1679,8 @@ unsigned is_submodule_modified(const char *path,
int ignore_untracked)
strvec_pushl(&cp.args, "status", "--porcelain=2", NULL);
if (ignore_untracked)
strvec_push(&cp.args, "-uno");
+ else
+ strvec_push (&cp.args, "--ignore-submodules=none");
prepare_submodule_repo_env(&cp.env_array);
cp.git_cmd = 1;
fixes it, I'm unsure at the moment if we should be adding the extra flag
here or setting the appropriate option in status when -uno and
--ignore-submodules=<option> are both omitted though
> What it is like debugging in Git? I have seen people writing debug
> statements(print statements in between the code) to figure out how
> things are working. But I guess we might not be able to do that. Do we
> have to create the exact environment that is been created by that test
> to check for the code?
Have you setup a config.mak file? Mine looks like
DEVELOPER = 1
SANITIZE = address,leak
CFLAGS += -ggdb3
CFLAGS += -fvar-tracking-assignments
CFLAGS += -fno-omit-frame-pointer
Which will build git with warnings enabled, debugging information and
enables the address sanitizer. Then you can run the git you have built
under gdb with
GIT_DEBUGGER=1 bin-wrappers/git
If you want to debug a particular test then I find adding `test_pause`
to the test and then running
GIT_DEBUGGER=1 git
in the shell that the test opens (it sets up the path appropriately).
You may want to add LSAN_OPTIONS=detect_leaks=0 to the commands above or
set up a suppressions file
I also use printf quite a bit but it does tend to break other tests
which can be awkward.
Best Wishes
Phillip