How to setup a Cron job to do a Git commit

I have been manually committing my git repository everyday. But then sometimes I forget.

Is it possible to write a shell script to do a git commit ?

I am finding it difficult because I dont know how to provide the commit message through script.

开发者_如何转开发NOTE

I am thankful to all the developers who have pointed out to me that this is not the way a version control system is supposed to be used. I agree. If I do a daily commit many of the versions will remain in broken state.

My case is different. I am not really interested in maintaining versions that wont break. I am more interested in keeping backup of my code. I work in a weird way on a remote machine through winSCP. I want something that will save every minor change I make so that just in case I do 'rm -rf' in some directory I wont lose most of my work.

This does not seem like a very good idea, but, if you still want to do it, something like this would suffice:

COMMIT = cat ~/commit_message
git commit -m $COMMIT

And, you can change ~/commit_message to whatever you like everyday.

Depending on what your exact use case is, you might want to take a look at Flashbake which uses git to do very frequent commits of a project - the idea is to help authors track their writing progress at a very fine level. It's not how git was designed to be used, but it's quite a nice idea :)

It shouldn't differ from a run-of-the-mill cronjob much. You can set the commit-message via the -m (message) option.

This being said, it seems odd that you would want to commit regularly like that. If you always commit with the same message and a non-separable amount of work, that kind of goes against the whole idea of version control.

I don't think it's that terrible of an idea to have some kind of version control as a backup.

It's just another use for Git than what it was specifically intended for.

Why should you use tools you aren't familiar with already to do your heavy lifting? Maybe there is a better practice approach, but using Git is arguably comparable to any other "backing up" mechanism, it just does it through another method. As long as you understand this and understand the implications it has on the repo, have at it.

EDIT

I didn't provide an answer in my response... Sorry about that.

I'd definitely say a good approach is to instead have it run a check maybe twice a day for the number of changes, and if the number is above a certain threshold, go ahead and run a commit. Set the commit message to be something descriptive of a backup. For instance, instead of using straight bash, you could programmatically set your commit message to include the date/time and some semblance of the files that the commit changed. This way, your commit messages aren't the same, and they are actually useful.

Fairly simple to do with Python or Ruby, which both have libraries for also running command line level things (like Git commit -am + message, or something similar)