Adding option for updating community cheats

[bernermic]

Hey @chrisallenlane,

working on the snap version is finished now :) I will do some final tests and release it to the public channel soon.
While working on the snap I had an idea I want to share.

Describe the solution you'd like
Cheat clones the community cheatsheets on initialization now. It would be cool to have an option to update this to the latest version via cheat cli.

Additional context
Something in the lines of cheat -update which updates all community based cheatsheets.

[exploide]

Maybe not just the community cheatsheets but all version controlled cheatpaths. I have my personal cheatsheets also in a git repository. Maybe a configuration option for conf.yml would be reasonable to include or exclude certain cheatpaths for updating?

[chrisallenlane]

Hi, @bernermic 👋

working on the snap version is finished now :)

Excellent! Thanks again, as always, for your work. 🎉

Cheat clones the community cheatsheets on initialization now. It would be cool to have an option to update this to the latest version via cheat cli.

Yeah, this has been on my mind too. I haven't given this a lot of thought, but here's something of an unstructured "brain dump" on the topic:

• I do think something along these lines would be generally useful
• That said, I don't want to re-implement git, or build out (possibly unneeded) dependency-managing code that I'll thereafter have to maintain. (My instincts are that there may be some hidden complexity here, especially when folks inevitably cause merge-conflicts in their cheatpaths).
• Perhaps this is better handled via a shell script/function than within the executable itself?
• If we pursue the shell-script approach, will the current cheat -d output be sufficient for the required scripting?

I haven't come to any conclusions yet. The above is where my mind is currently, though. Feel free to share any input you may have. Thanks.

[bernermic]

Hey @chrisallenlane ,

I did not think of the conflicting part. So doing the update in a script should be good enough😀
I added something in this line to the snap version.

Greetings
Michael

[targodan]

Not sure if this should be its own issue or if it fits in here, but:

I'd also really like an auto upload feature for personal cheatsheets as well. Something where I can cheat -e mysheet and after closing the editor an automatic git add <sheetfile> && git commit -m "Edited <sheetfile> && git push.

About the implementation:
I found a golang implementation of git https://github.com/go-git/go-git, but I don't think that's the best way to go. I have two other ideas:

1. A pseudo-client based on the golang process api. Just call the git command as a shell command from go. This would only introduce an optional dependency.
2. Make your life easy and implement a script-hook mechanism. That way the user would be able to define hooks for actions such as having edited a sheet. Then it's up to the user (or some contributed scripts) to do things such as git committing and pushing and so on.

For option 2 to be really nicely extensible you'd have to expose some information to the called hook, such as the path to the edited cheatsheet, maybe the directory it's contained in for ease of use and so on. I guess exposing this either via parameters to the hook or via environment variables would be nice.

You could then also provide a "on-start" or "once-a-day" hook or something where the community repo could be updated right after the cheat exe is started.

[chrisallenlane]

@bernermic has taken a first pass at implementing this with #617.

[jpmvferreira]

If I may give my two cents and suggest an alternative way of doing things, if a flag were to be implemented where one could refer to a given cheatpath by its name (e.g.: cheat -n community or cheat --name community), then allowing the usage of git right after this command would be equivalent of using git inside the corresponding directory for the cheatpath 'community'.

This would allow the user to decide when to commit, push or pull, as well as include more insightful commit messages, without having to go to the directory of that given cheatpath.

pass provides both of these behaviors, if I'm not mistaken, as it automatically commits your changes when you make modifications, but it also allows you to interact directly with the underlying git repository without having to change directories.

[chrisallenlane]

Bit of a note-to-self here:

I'm currently re-writing all of the project documentation. I have temporarily removed @bernermic update script information from the README, and will add it to the Wiki with improved documentation.

[chrisallenlane]

The more I think about this, the more essential I realize this is.

I also think I was too timid previously. It's probably not all that hard to:

1. Iterate over every cheatpath
2. iff the cheatpath is a git repository
3. ensure that the repo is not "dirty"
4. git pull

If the branch is dirty, I can just fail out with an error message telling the user to clean it up. As long as I don't attempt to sort out any of the conflicts within cheat, I don't think this should be all that hard to do.

Anyone reading this is welcome to share feedback on this approach. Unless someone has a convincing argument as to why this is a bad idea, I'll probably take a crack at implementing it in the near-term.