Closed rachelambda closed 4 years ago
rachelambda
commented
4 years ago Another interesting question that arises from this is what to do if the script fails, I personally think the best thing to do would be to run git reset --keep 'HEAD@{1}' in the repository in case it fails in order to revert to the latest head, effectively undoing the pull.
dylanaraps
commented
4 years ago How do we distinguish between network error and a failed merge (or the myriad of other possible problems)? We can't really do something like that if we run the risk of mangling a user's repository. Another question is, should the package manager do anything on failure in the first place? Is this not best left up to the user to repair to their liking?
Or... am I wrong and this command is safe in all cases?
rachelambda
commented
4 years ago I'm not sure, to be honest. It reverts to the last HEAD, however I'm not sure what this will refer to in all cases. However executing it repeatedly doesn't result in going back several commits and running git pull goes back to the latest commit. That being said failing the package manager is always a good option.
dylanaraps
commented
4 years ago I think it's best we just keep the current behavior (package manager fails). Let me know your thoughts about the update hook as well. :+1:
Right now it's possible to use post-install for post-install messages which is great, however I think it'd be usefull to have some way of messaging the user upon repository update.
For instance if you're switching from symlinks to submodules you might want to tell the user they can remove the old repo used for symlinks.
Maybe there could be a post-update executable in the root of the repository which gets run after pulling from the repository? I feel like this would still be very KISS as opposed to the mail solutions many other package mangers use.
Another use for this executable could be to pull files from non git sources to the repository if someone decides they want to do that.