Repository navigation
Better x-revision handling #16
Description
Activity
No. We want be explicit to avoid accidents, i.e. make operation inputs independent of Hackage state.
Having
--set-rev=Nwould be fine.Having
--set-rev=Nwould be fine.Sounds good to me.
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: Nto the cabal file and deleting this line again afterwards.
A flag like
--auto-revimplementing 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--publishflag.)
I'd like to use
hackage-clifor packages where I don't track thex-revisionfield in the git repo. Currently, when I try to upload a second revision for such a package withpush-cabal --incr-rev, I get the errorCould
--incr-revpossibly be changed to simply increment the latest revision?