Why is the option allow_empty_commits default to be true?

[w568w]

There is an option named allow_empty_commits that controls whether an empty commit is allowed. However, it is true by default, and:

1. caused a lot of confusion. This package commits every hour and the developer doesn't know how to stop it;
2. did not make sense. There is no effect to push an empty commit to AUR, which only contains files for building and packaging.

--allow-empty has been added since the initial commit with no reason. So I assume that it is kept true for backward compatibility.

I suggest making it false by default.

---

Q: But it is a break change...!

I don't think the change will really "break" anyone's workflow. After all, you can publish a new major version for it.

[KSXGitHub]

1. caused a lot of confusion. This package commits every hour and the developer doesn't know how to stop it;

Tell the developers to read the documentation. There's no fixing skill issues.

2. did not make sense. There is no effect to push an empty commit to AUR, which only contains files for building and packaging.

It makes sense for many of my use cases, where CI can sometimes make no change. And I don't want the CI to just fail.

[w568w]

Tell the developers to read the documentation. There's no fixing skill issues.

I am not defending the developer; it is indeed his fault for not reading the documentation at all. However, isn't it necessary to emphasize this rather unusual default value in the documentation? I think this has confused more people than just him.

I don't want the CI to just fail.

This is actually nothing to do with the default setting.

I suppose your goal is to prevent the CI from failure, and there are many ways to achieve that. I believe that using --allow-empty blindly is one of the worst options. Maybe silently fail and print a warning message in that case?

[KSXGitHub]

I actually checked build.sh and saw that allow_empty_commits=false doesn't fail.

[w568w]

Thanks for your quick fix. 🚀