Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better x-revision handling #16

Open
sjakobi opened this issue Oct 1, 2020 · 3 comments
Open

Better x-revision handling #16

sjakobi opened this issue Oct 1, 2020 · 3 comments

Comments

@sjakobi
Copy link
Collaborator

sjakobi commented Oct 1, 2020

I'd like to use hackage-cli for packages where I don't track the x-revision field in the git repo. Currently, when I try to upload a second revision for such a package with push-cabal --incr-rev, I get the error

The new x-revision must be 2

Could --incr-rev possibly be changed to simply increment the latest revision?

@phadej
Copy link
Collaborator

phadej commented Oct 2, 2020

No. We want be explicit to avoid accidents, i.e. make operation inputs independent of Hackage state.

Having --set-rev=N would be fine.

@sjakobi
Copy link
Collaborator Author

sjakobi commented Oct 3, 2020

Having --set-rev=N would be fine.

Sounds good to me.

@andreasabel
Copy link
Member

Pondering whether to implement --set-rev=N, I got doubts that it is worthwhile:

  • It only sensibly applies to pushing a single cabal file (but maybe exactly this was the intended use case).
  • It does now save much work over manually adding x-revision: N to the cabal file and deleting this line again afterwards.

A flag like --auto-rev implementing the OP would offer enough net gain, though.
Note that the default dry-run mode already helps to avoid accidents. (At least, I personally always first do a dry run before supplying the --publish flag.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants