Use of `rel/` dir in workdir makes workdir unclean

[joonas-fi]

Problem

Scenario: compile Go app. Go auto-embeds Git metadata such as workdir clean status.

function61/gokit/app/dynversion propagates this to version number as -dev suffix to indicate all builds are dev versions:

https://github.com/function61/gokit/blob/f6c12a3fbe5e9b101501b9ee9c0709258543e1de/app/dynversion/version.go#L47-L49

Partial fix

Shipped 7785765 to at least not make all GitHub workflow -initiated builds not auto-mark the workdir as unclean.

Footgun

Since Git does not track directories, the fact that say buildkit-golang creates rel/ directory before build does not make the workdir unclean from Git perspective.

But let's say we have app we want to cross-compile both for:

1. amd64
2. riscv64

When we start building item 1 the workdir is clean because rel/ dir is empty at start of build.

Now when we start building item 2 the workdir is unclean because the item 1 is in there.

Result:

Build	Version
amd64	1.2.3
riscv64	1.2.3-dev

That's hell of a footgun.

For consistency we'd probably like to create the rel/ directory and drop some dummy file in there, better the possible -dev suffix to apply to all executables instead of n > 1. This would be worsened by building those in parallel, then it would be nondeterministic which versions are marked dev..

This rel/ dir affecting workdir cleanliness state could be mitigated by .gitignore'ing the dir, but am not sure if it's nice to impose that to every project.

Have the build result directory be outside of the VCS workdir?

This would solve the footgun thing. How to do this properly without adding too much complexity to all users?

Would we realistically be able to maintain clean workdirs in ALL situations?

There are concepts like code generation which by design make the normal build look like it's always unclean.

Maybe it'd be OK to accept the fact that with some projects it's not pragmatic to maintain the clean state.