Re: [RFC] TODO in read-cache.c

From: Taylor Blau <me@ttaylorr.com>
Date: Apr 9, 2019, 02:04 UTC
Message-ID: <20190409020416.GB81620@Taylors-MBP.hsd1.wa.comcast.net>
In-Reply-To: <CAMknYENJogZ6vxs3zxivD3TPtDnfE9DFQDTwri+eLJmTwr4zxw@mail.gmail.com>

Hi Kapil,

Welcome to Git! I am thrilled to see new faces on the mailing list.

On Sat, Apr 06, 2019 at 05:43:56PM +0530, Kapil Jain wrote:

Show 22 quoted lines

> On Sat, Apr 6, 2019 at 5:33 PM Duy Nguyen <pclouds@gmail.com> wrote:
> >
> > trace2 API can already take 'struct repository' (the_repository is a
> > pointer to 'struct repository'). I'm pretty sure the purpose is to
> > _not_ pass the_repository (because it implies the default repo, which
> > is not always true). Which means you read-cache.c's functions need to
> > take 'struct repository *' as an argument and let the caller decide
> > what repo they want to use.
>
> right, i mistyped.
>
> > In some cases, it will be simple. For example, if you have a look at
> > repo_read_index(), it already knows what repo it handles, so you can
> > just extend read_index_from() to take 'struct repository *' and pass
> > 'repo' to it.
> >
> > Be careful though, repository and istate does not have one-to-one
> > relationship (I'll leave it to you to find out why). So you cannot
> > replace
>
> should i run all the tests after making the changes, or are there some
> specific ones.

It is a good rule of thumb to run 'make' in the testing directory (this is 't') at least once before sending patches to the list.

Generally when I am writing something, I will often be fixing some bug and either (1) have a test that I know I am trying to fix, or (2) write a test that is initially broken, which I then aim to fix.

You can see a good example of this in the last series that I sent to the list [1]. In 2/7, I introduced several failing tests, and then fixed them in the later commits in the series.

I also like to have a full suite of tests run on multiple platforms before sending to the list. I have my fork [2] configured with TravisCI, which runs builds on a number of different architectures/compilers for completeness.

Git already has a .travis.yml in the repository, so you don't have to do any work other than authenticate with TravisCI.

Thanks, Taylor

[1]: https://public-inbox.org/git/cover.1554435033.git.me@ttaylorr.com/ [2]: https://github.com/ttaylorr/git