Open eclairevoyant opened 7 months ago
Sure, why not. One way I could see to handle this:
pinned
attribute to each pin entrypin
and unpin
subcommand to the CLI to modify that value--pin
flag to the add
subcommand which will set pinned
to true on creationMy only worry is that this terminology could be confusing due to the double meaning of "pinning". Not sure how else to call it though
An alternative would be to allow specifying which pins to skip while updating. Currently we can say update foo bar
to only update certain pins, so maybe some --skip
or --exclude
flag could be added to do the opposite. I think I'd personally like this solution a bit more, but not sure how well it would fit your use case.
My use case is to prevent updating inputs when I know they're broken after a certain rev, i.e. I'd pin to the last known working rev.
I would lean towards the first option, since it would:
I do see the issue about calling it a "pin", though :confused:
How about "freeze"/"frozen"?
Yes, I think that makes sense.
@eclairevoyant mind having a look at #78 and testing it?
To add a GH source at a specific commit is explained as
In my case, I'd like to keep that source pinned to
<rev>
even after runningnpins update
. Is this possible?