prerelease fails to find my CHANGES.rst

[mgedmin]

I've created a new project and am about to make my first release.

I've created a file called CHANGES.rst, with the following contents:

Changelog
=========

0.8.0 (unreleased)
------------------

- First public release.

I run prerelease and I get this:

Run pyroma on the package before tagging? (Y/n)? n
Do you want to run check-manifest? (Y/n)? n
This is NOT a clean checkout. You are on a tag or you have local changes.
Are you sure you want to continue? (y/N)? y
WARNING: No history file found

Why is my changelog not recognized?

(I have zest.releaser 6.15.2, which is the latest currently available version.)

[mgedmin]

Looking at the source code, I can see it's because I haven't committed the file yet.

(I have git added CHANGES.rst, thinking that it might help, but haven't committed it yet -- I wanted zest.releaser to update the date for me.)

I'm solving a similar problem in check-manifest, and my Git.list_versioned_files() method, which uses git ls-files -z, lists files that have been added but not yet committed, in addition to files that have been committed.

I see you use git ls-tree -r HEAD --name-only. Is there any particular reason? Would you consider switching to git ls-files?

(The -z makes git output filenames with non-ASCII characters without magical "\xAA\xBB" quoting rules, but it also requires you to split on '\0's rather than '\n's.)

[reinout]

Well, zest.releaser assumes that everything is ready for release when you're calling zest.releaser. "Ready for release" sure doesn't mean "I have uncommitted changes". At least, that is my assumption.

The warning about "aargh, you have local changes" comes from the same line of thought :-)

Normally, you have tests that run automatically. Why would you want to "sneak" in something under the cover of the "prerelease" step? That's effectively what's happening. I'd consider it a corner case, initially.

Now.... that being said.... your git ls-files sure looks simpler than the longer version we're using. So your version looks much nicer. We're probably not using it because we simply didn't know about it 10 years ago or if the method didn't exist yet, then.

So: it sounds pretty good to switch to your proposed call. The "hey, you have uncommitted files" warning takes care of most of my worries, I guess?

[reinout]

Looks like your git ls-files works just fine: #322

[reinout]

I have released 6.18.1