concerns about git

concerns about git

[deepwinter]

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)
-- 
View this message in context: http://www.nabble.com/concerns-about-git-tp19959918p19959918.html
Sent from the git mailing list archive at Nabble.com.

Re: concerns about git

[Shawn O. Pearce]

deepwinter <deepwinter@winterroot.net> wrote:
> 
> 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)

Because every working copy is equal.  They all have a copy of the
project's metadata in the .git/ directory.

If you want a backup, create one with clone and push to it every
so often, e.g.:

  # one time setup
  $ git clone --bare . /some/other/drive/project.git
  $ git remote add backup /some/other/drive/project.git

  # 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.

Who needs a central repository like SVN or CVS when you can have 3
or 4, on just as many disks, in different buildings, and possibly
different parts of the world.  Yes, I keep my real work that I care
about backed up under different providers, with their data centers
located in different countries.  And of course extra copies locally,
in case the 'net is down.

-- 
Shawn.

Re: concerns about git

[David Tweed]

On Mon, Oct 13, 2008 at 7:19 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>  # 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__________________________
david.tweed@gmail.com
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

Re: concerns about git

[Brandon]

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/

On Mon, Oct 13, 2008 at 2:40 PM, David Tweed <david.tweed@gmail.com> wrote:
> On Mon, Oct 13, 2008 at 7:19 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>>  # 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__________________________
> david.tweed@gmail.com
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: concerns about git

[Ciprian Dorin Craciun]

On Mon, Oct 13, 2008 at 10:51 PM, Brandon <siamesedream01@gmail.com> wrote:
> 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/
>
> On Mon, Oct 13, 2008 at 2:40 PM, David Tweed <david.tweed@gmail.com> wrote:
>> On Mon, Oct 13, 2008 at 7:19 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>>>  # 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__________________________
>> david.tweed@gmail.com

    I have the same problem as David, but I manage it by using a
symlink. That is my .git folder is a symlink to the real repository
(possibly on another partition). (So far I had no problems with this
setup.)

    Ciprian Dorin Craciun.