Re: Git Questions

Tom Schinckel [off-list ref] writes:

The reason I want to do that is so I can set up blind commits that I can
add in a anacron job or something. The information about the files isn't
really important

Thanks for the help: I'm using git in a uncoventional way. 

OK. AAUI, you're abusing git as a backup system.

That's definitely not what git (and other VCS) is meant for. What git
is good at is to create clean "changesets" (i.e. _you_ tell git when
you have something worth recording in history), and merging. But since
git is fast and disk-efficient (if you run git-gc from time to time),
it can probably be a good backup tool too.

If you want to run "git commit" each time you save a file, you can
probably program your editor to do so, or use something like
fam/inotify. But it's probably not reasonable, you'll quickly end-up
with thousands of file revisions (imagine the result if you run a
script like "for i in $(whatever big thing); do echo $i >> file; done").
If I were you, I'd set up a cron job to do the commit once every (few)
minute(s). If the project is not too big, it will take less than a
second, and commit will fail silently if you have no modification to
commit.

You'll want git to automatically add any new file, so you'll run
something like

git add .

# Remove deleted files.
# There's probably a better way, but I don't find it.
git-ls-files --deleted -z | git-update-index --remove -z --stdin

git commit -m backup


I don't think your idea of taking the output of git-status as a commit
message is necessarily relevant: this information is anyway in the
commit, git-show and friends will show it. I'd say the commit message
is irrelevant, and you can provide a dummy one. Otherwise, someone
answered in the thread.

-- 
Matthieu

On 8/20/07, Matthieu Moy [off-list ref] wrote:

OK. AAUI, you're abusing git as a backup system.

Just as a point, I think a better word is "archive system". (Backups
are more for replicating current state in the event of a system failure.
Clearly _if_ you're working on a well defined project, careful repository
management is a good idea. (One of the key things you lose
from automatic commits is the ability to reliably bisect stuff.)

However, not all the work one does on a computer is so
focussed and well-demarcated, so in other cases keeping
a history so you can, eg, look at what you're research codebase looked
like when you generated the results you pasted into a paper
on July 12 2005 is a useful ability, even if that sort of "looseness"
wouldn't be appropriate in "product" based development.

The nice thing about git is that it's so efficient at the low levels
it can be used for both "proper" SCM and archival storage.

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee