Re: [GSoC] Intro and Micro-project

From: Taylor Blau <me@ttaylorr.com>
Date: Mar 21, 2023, 17:17 UTC
Message-ID: <ZBnmsoRmQGKkQt+S@nand.local>
In-Reply-To: <CAPNJDgcauhz_NraSPTQfiDM61gyghSJShZLPUtt5HOr2xKysZg@mail.gmail.com>

Hi Edwin!

On Tue, Mar 21, 2023 at 02:38:34PM +0000, Edwin Fernando wrote:

Show 5 quoted lines

> Hello,
> I am Edwin, a first year undergrad in the department of computing,
> Imperial College London. This is my first message to this mailing
> list! I want to work on the micro-project "avoiding pipelines in test
> scripts".

That sounds great! I assume that you meant avoiding pipelines where the 'git' executable is in a non-terminal position of the pipe, e.g.:

    $ git blah | <something else>

Since if "git blah" exited with a non-zero code or crashed, etc., then we wouldn't see the failure since the pipeline would suppress it.

That has been a long-standing goal within the test suite, and I think that it's a great project to get you started. It'll ensure that you have all of the bits in the right place to get Git running on your machine and that you're able to run the tests.

Show 6 quoted lines

> I'm really excited to work on such a massive project (ie, git, not the
> microproject) and be in contact with the people who put it all
> together. I'm curious about how software development works at this
> scale, since it feels quite different from the small projects I've
> used to work on. I use bash quite frequently for automating tasks, and
> I have experience in C, through a uni project of making an assembler.

:-).

> I found and looked at a few places with pipes. I have a few thoughts
> and questions on making a change. Firstly (if this is relevant), how
> do I ensure that the file I write the std output to doesn't have a
> name clash with other such files made during tests?

Each of the tests runs in their own "trash directory", which you can keep around after the tests are finished running if you invoke them with the '-d' flag. More information about each of those flags is available in t/README, as is information about the test suite as a whole.

I would also recommend that you take a look through t/test-lib.sh and t/test-lib-functions.sh, as those give a good overview of both (a) some of the internals of our integration testing library, and (b) some of the convenience functions available to you as a test author.

Looking at some example tests in the tree may be useful, too. You might want to check out t/t5318-commit-graph.sh as an example of our modern test-writing style.

Let us know if you have any questions or want any pointers on getting started.

Thanks, Taylor