sivark
commented
9 months ago Ha, I had the same thought when searching for an emacs package, and stumbled across this. Since you're looking for discussion, I'll share my current thoughts.
Commits are appends to the git history and help avoid accidental data loss, so I imagine that frequent commits are a good thing. One can then garbage collect on the git side, or even (retroactively) "compact" commits/history as optimal eg. with something like automatic rebase/squash.
alienbogart
I recently screwed my entire org-roam library by accidentally pressing "sync" button in Orgzly. It took me a while to clean up the mess and I realized that I finally needed to find some time to figure out how to not to screw up like that ever again.
This project is awesome and I love it. However, since I constantly edit my org files, it got me wondering if making tiny commits for every single change is actually a good thing. Not that it bothers me now, but I don't know how many commits in the git log is too many. Never had this problem before and probably using this package won't cause any troubles for me ever.
Just to clarify, this isn't a "feature request" or anything, just a simple thought that haunted me for a minute, so I decided to post it here for posterity.
What do you think of the possibility of making the commits granular, i.e., "commit once a day" or "not more than once per every hour"? Basically, checking if the last commit was "x time ago", just keep the stuff staged but not committed. The next time when it's time to commit, check again and if it's due - commit everything, including what was previously staged.
Correct me if I'm wrong, I saw
gac-debounce-interval, but I think it's serves a different purpose.Anyway, as I said - just a thought, nothing else. If I get bored or something, I might try to implement that myself. Once again, many thanks for this very useful package.