threads / rfc / 41847

RFC patcht/perf: "make clean" from the top-level to clean results

Subject: [RFC/PATCH] t/perf: "make clean" from the top-level to clean results

## tl;dr

3 messages between Mar 28, 2016 and Mar 29, 2016. Diffs are folded; open one to read it.

replies: 2people: 3as markdown or json

Junio C Hamano· Mar 28, 2016, 20:16 UTC · lore

Running "make clean" from the top-level after running perf tests left t/perf/test-results/ directory and tons of files in it. At least "make distclean" should turn things back to pristine state.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 * Perhaps I am missing some reason why this was deliberately left
   out when we added t/perf/Makefile that does have the clean
   target?  Cc'ing the suspects found by "shortlog t/perf".
 t/Makefile | 1 +
 1 file changed, 1 insertion(+)
Show changes to t/Makefile +1 −0
diff --git a/t/Makefile b/t/Makefile
index 18e2b28..e0aef9a 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -48,6 +48,7 @@ pre-clean:
 clean-except-prove-cache:
 	$(RM) -r 'trash directory'.* '$(TEST_RESULTS_DIRECTORY_SQ)'
 	$(RM) -r valgrind/bin
+	cd perf && $(MAKE) clean
 
 clean: clean-except-prove-cache
 	$(RM) .prove
Jeff King· Mar 28, 2016, 20:20 UTC · re: Junio C Hamano · lore

Re: [RFC/PATCH] t/perf: "make clean" from the top-level to clean results

On Mon, Mar 28, 2016 at 01:16:50PM -0700, Junio C Hamano wrote:
Show 10 quoted lines
> Running "make clean" from the top-level after running perf tests
> left t/perf/test-results/ directory and tons of files in it.  At
> least "make distclean" should turn things back to pristine state.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> 
>  * Perhaps I am missing some reason why this was deliberately left
>    out when we added t/perf/Makefile that does have the clean
>    target?  Cc'ing the suspects found by "shortlog t/perf".
I don't think I've ever touched the "clean" code path.

This change is fine by me. I have noticed that the contents of t/perf/build can pile up and consume quite a lot of space, as they are all full builds of git. They're a little more expensive to reproduce than some other things, but they're inherently still a cache. I think your patch is doing the right thing.

-Peff

← back to recent threads