part of issue954

Sorry, we just merged this live via Zoom. The merge button works fine with our workflow if we remember to prepend "[main] " to the merge commit message.

If you are about to merge this, could you wait a little bit until I confirmed that the buildbot workers are running correctly? This way, we could also test issue952 at the same time.

Done.

Thanks, Jendrik! I would also ignore benchmark64, not just benchmark32. The way I read the Makefile and issues, both are meant to be created, it just requires some coaxing from the outside with environment variables, as in "make BITWIDTH=32 && make clean && make BITWIDTH=64" or whatever (didn't check the variable names and syntax).

I agree and moved the ignore patterns to the subdirectories.

I think the microbenchmark ignores don't make a lot of sense as global rules. Why do we need to enforce that these microbenchmarks are in a subdirectory of the relevant experiment directory? What if we want to do two microbenchmarks for a given issue? What if we want to do one but don't like plain Makefiles?

I think the rules are the way they are because that's what we needed for the first microbenchmark, and since then they have forced some of the other microbenchmarks into an awkward directory shape because we didn't like touching the .hgignore file for this because that's a fairly invasive change for "just" an experiment. But that reason doesn't apply in git, where we can simply put a .gitignore into the relevant experiment directory.

If you look at the five microbenchmarks we currently have, in three of them the "microbenchmark" directory is the *only* thing in the experiment directory, which doesn't make sense to me, and I would guess the only reason why this is the case is because we didn't want lots of different rules in .hgignore on a per-experiment basis.

I think a .gitignore file in the relevant benchmark directory with

/.obj/
/Makefile.depend
/benchmark

would be better and would allow us more flexibility for future benchmarks.

Fine with me. If the merge doesn't match our workflow, it might be a bit messy to undo it but it should be possible. If it matches but only if you use the correct settings, we might want some protection against wrong configuration. But that discussion probably doesn't belong here. Maybe talk to Patrick as well, he is working on the push hooks in issue973.

I'm done with handling your comments. Can I merge this?

I'd use the GitHub merge UI to check whether we can make it confirm to our workflow.

Here you go: https://git-scm.com/docs/gitignore

Can you point us to a description of the .gitignore syntax?

Pull request: https://github.com/aibasel/downward/pull/1

Feel free to directly edit the .gitignore file on GitHub to save turnaround time.