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