Closed oreinert closed 11 months ago
2 weeks since submission without any reaction - I'm guessing there's something about this PR that doesn't sit right with you. Would you mind sharing what it is?
Hey @oreinert. Sorry, no. I've just been busy and then forgot about it. This one requires a bit more concentration to review so I put it off and then didn't get around to it. Let me do that now.
OK. I get what you are trying to do. What I used to do is the following:
local ret=0
homeshick refresh -b || ret=$?
[[ $ret -ne 87 ]] || homeshick pull -b
But that's also just a bunch of code one could avoid with the new behavior. I'm kind of on the fence about this because it changes the behavior some people may rely on :-/
What do you think?
What I would really like is for homeshick
to be able to accurately track any change happening to an upstream castle, which is something it just can't do right now. This means there should be a single command which can achieve the following goals:
If I had free hands to make changes, I would
check
with an optional DAYS argument, with the same semantics as for refresh
,link
with an optional FROM argument, which is a hash that's an ancestor to HEAD, and, if given, enables removal of links obsoleted by updating along FROM..HEAD, andrefresh
into a combination of check+pull+link to achieve the goals above.With all that, I could just add homeshick --batch refresh 5
in my .rc file and forget about it. More careful people than me could just skip enabling batch mode to be queried along the way, but still gain all other benefits.
How exactly this can be realized is something to be debated, though. I thought this PR might be a good place to start - if nothing else, to start the discussion. :-) It would interest me to know whether you think the goals outlined above are a good idea at all, or not.
In general, I would not make breaking changes to anything except the refresh
command, and then only to make it more potent and thereby easier to use. Because in its current form I think it's the odd one out, and a bit pointless TBH.
All fair points. Merging. You touch upon some discussions that have been had in #71 and #79.
Right now I would like to maybe start on a new version that uses docopt.sh for argument parsing, records.sh for logging and μpkg for managing those dependencies (and optionally installing through it).
My current blocker is getting autogenerated completion to work for docopt, but completion scripts in general are such a pain. And everytime I start work on it my brain hurts and I just want to procrastinate instead 🤣
I know, you didn't ask for my opinion about your plans, but... well, I'm not so keen on it. And I find myself unable to succinctly express why not (not for lack of trying). Also, it's off-topic for this PR. If you'd like to engage in that discussion, we should find some other medium.
While being a great tool,
homeshick
can be a bit awkward when used in an automated fashion. Its--batch
mode means "pick the (safe) default option" for every user prompt, which has the unfortunate effect of making most commands rather impotent when run in batch mode.Because of this, I currently have to write
echo 'y' | homeshick refresh
to automate the updating of all castles at regular intervals, which is a bit corny. I'd much prefer to just writehomeshick --batch refresh
.In this pull-request, I propose a way to achieve that by allowing commands to change the default prompt response when running in batch mode. The initial application is the refresh command.
This implies changing the meaning of
--batch
mode to be "just do what's expected without bothering me" in order to make it more suitable for automation. While still requiring--force
to make potentially destructive changes, of course.