Thread (3 messages) 3 messages, 3 authors, 2021-03-08

Re: [PATCH] Makefile: generate 'git' as 'cc [...] -o git+ && mv git+ git'

flat view

From: Jeff King <hidden>
Date: 2021-03-08 18:26:47

On Mon, Mar 08, 2021 at 01:38:32PM +0100, Ævar Arnfjörð Bjarmason wrote:
quoted
quoted
Change the compilation of the main 'git' binary to not have the CC
clobber 'git' in-place. This means that e.g. running the test suite
in-place and recompiling won't fail whatever tests happen to be
running for the duration of the binary being regenerated.
I am not sure why I would want to support the workflow this is
trying to help.
Because it also allows me and others to do more testing on patches to
git.git.

If I'm working on a patch to e.g. git-fsck I might be doing
edit->save->some-tests, where "some-tests" are a subset of the test
suite I think is relevant to fsck.

But after doing N commits with passing tests I might notice that some
other part of the test suite I didn't expect to have anything to do with
fsck broke because I wasn't running that test.

I wasn't running that test because I'm not going to wait 10-15 minutes
for it to run while actively editing, but will wait 30s-1m for 10-50
test files to run.

So I can also have the full test suite running in a loop in some side
window that'll give me a headsup if the "while do-full-tests; [...]"
loop breaks, at which point I'm likely to investigate it sooner than
otherwise, and not waste time going down the wrong path.

You can of course do that now, but it requires having a worktree on the
side or whatever, which isn't always ideal (sometimes I'd like to have
these tests on uncommitted changes).
I don't always use it, but I have a "ci" script[1] that just runs the
test on each individual commit in a loop. The interesting things about
it (beyond a simple loop) are:

  - it operates in a worktree (that copies the config.mak from the main
    worktree if necessary).

  - it uses Michael Haggerty's git-test[2] to memoize results for a given
    tree. That makes it reasonable to leave running in the background,
    where it will only use CPU when there's something useful to do.
    I also use git-test for "git rebase -x", so a final "is each commit
    OK" check usually runs instantly, because the results are cached.

  - it uses inotifywait to decide when HEAD has been updated. This is
    mostly a fun hack. It could also just poll every 10 seconds or
    whatever.

  - it triggers a custom command when the tests fail. I can share my
    sad-trombone.wav with you if you need. ;)

Your mention of 10-15 minutes makes me wonder why your system is so
slow, though. I generally run the whole suite (minus cvs/svn/p4 bits) in
under a minute. I know it's _much_ slower on Windows, but I didn't think
that was your platform.

(In general, I'm mildly negative on your patch here. I have definitely
run into this myself, but I think having the test suite loudly complain
is a good way to remind you that you have not in fact run the whole
suite on a given build).

[1] https://github.com/peff/git/blob/meta/ci
[2] https://github.com/mhagger/git-test

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help