concerns about git

i've been looking into using git for some version control and it looks great.. except for 1 thing that really disturbs me. why is the .git repository stored within the working copy? this is seems like a recipe for accidental deletion. if you are an individual using version control lets say for just your own work, there is a lot of security that is gained from at least having your repository within a different directory, or better on a different partition. this ensures that accidental deletions or hard drive crashes are less likely to result in loosing the ENTIRE project! of course,
accidentally deleting your working copy is stupid, but it does happen. git
seems to offer no protection against this kind of mistake for the individual coder.. or is there some way to have git put the actual repository files in a different directory? (can't find info on that)

 # then every once in a while, or from a cron job
 $ git push --all backup

Of course since Git is distributed you can you use this same approach to make backups to other systems. You can even edit the .git/config to give the [remote "backup"] section more than one url line, so that "git push --all backup" will send updated copies to multiple locations at once.

Quoted 8 lines · Shawn O. Pearce

 # then every once in a while, or from a cron job
 $ git push --all backup

Of course since Git is distributed you can you use this same approach to make backups to other systems. You can even edit the .git/config to give the [remote "backup"] section more than one url line, so that "git push --all backup" will send updated copies to multiple locations at once.

Another advantage of 'git push'ing to another repository (possibly via cron) as backup is that (for technical reasons) git push has to 'parse' the new changes to your repository in order to push, so it is likely to spot corruption (eg, dying disk) at that time and when you can decide what to do about it. (I have enough backups all over the place that I don't worry about not having a 'copy' of any stuff I care about, but that there'll be some fatal corruption I don't notice immediately that then gets propagated everywhere rendering them useless.)

--
cheers, dave tweed__________________________ [email protected]
Rm 124, School of Systems Engineering, University of Reading. "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
--
To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

You can use "git config core.worktree <location>" to create a ".git" folder that manages a working copy in another location.

I know some of the GUI tools don't support this though so I would only use it if truly necessary . (For example a using git to manage a mapped network drive, it would be faster to keep the ".git" folder on the local harddrive)

More documentation here: http://www.kernel.org/pub/software/scm/git/docs/

Quoted 23 lines · David Tweed

Quoted 8 lines · Shawn O. Pearce

 # then every once in a while, or from a cron job
 $ git push --all backup

Of course since Git is distributed you can you use this same approach to make backups to other systems. You can even edit the .git/config to give the [remote "backup"] section more than one url line, so that "git push --all backup" will send updated copies to multiple locations at once.

Another advantage of 'git push'ing to another repository (possibly via cron) as backup is that (for technical reasons) git push has to 'parse' the new changes to your repository in order to push, so it is likely to spot corruption (eg, dying disk) at that time and when you can decide what to do about it. (I have enough backups all over the place that I don't worry about not having a 'copy' of any stuff I care about, but that there'll be some fatal corruption I don't notice immediately that then gets propagated everywhere rendering them useless.)

--
cheers, dave tweed__________________________
[email protected]