← Back to context

Comment by mauvehaus

7 months ago

The idea that git offers a 'clean' command was revelatory to me. Your build system probably shouldn't need to know how to restore your environment to a clean state because your source control should already know what a clean state is.

That's sort essential to serving its purpose, after all.

I haven't yet run into a scenario where there was a clean task that couldn't be accomplished by using flags to git clean, usually -dfx[0]. If someone has an example of something complex enough to require a separate target in the build system, I'm all ears.

[0] git is my Makefile effect program. I do not know it well, and have not invested the time to learn it. This says something about me, got, or both.

The problem with `git clean` is -X vs -x. -x (lowercase) removes EVERYTHING including .env files and other untracked files. -X (uppercase) removes only ignored files, but not untracked files.

If there is a Makefile with a clean target, usually the first thing I do when I start is make it an alias for `git clean -X`.

Usually, you want to keep your untracked files (they are usually experiments, debugging hooks, or whatever).

  • This. I have no urge to have git "clean" my project, because I'll lose a ton of files I have created locally. Rather, I want the project know what it creates when it builds and have the ability to clean/purge them. It's a never ending source of frustration for me that "gradlew clean" only cleans _some_ stuff, and there's no real "gradlew distclean".

    • Hmm, I wonder what's the best way™ to, er "locally backup" those files, in such a way that no git-clean invocation will remove them without promoting.

      All I can think of are things like periodically copying them to another folder, or give them a different ownership needed for edit/delete, etc.

      Unless there's some kind of .gitpreserve feature...

      2 replies →

  • You are almost certainly right that I was using -X. It's been a while since I had to deal with git.