All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Haney <markh@abemblem.com>
To: git@vger.kernel.org
Subject: Re: Help with repo management.
Date: Fri, 20 Apr 2012 08:39:47 -0400	[thread overview]
Message-ID: <4F915913.10908@abemblem.com> (raw)
In-Reply-To: <CAH5451nL+BiZPo-cWHwYC4GkA=pT3zgBXi_M-TB-qgDfmy7yow@mail.gmail.com>

On 04/19/2012 07:49 PM, Andrew Ardill wrote:

>
> First things first, don't think that just because a bare repository
> does not have a working copy that it doesn't have all the data. Having
> a local working copy and a bare repository on a server _is_ keeping
> two separate copies of your data handy, just one is not immediately
> accessible (you have to check it out first). This may be your
> understanding, but it was unclear so I thought I would clarify.
>
> In terms of pushing to a remote, it is best practice to NOT push to a
> repository that has a checked out working copy. The main reason for
> this is that it becomes much easier to lose data, which is bad.
>
> Instead, if you want to work on SERVER as well as some other machine,
> it is safer to checkout the bare repository to another repository on
> SERVER, pulling and pushing to the bare repository in the same fashion
> as you would from a remote machine.
>
> Some more explanation can be found at
> http://gitready.com/advanced/2009/02/01/push-to-only-bare-repositories.html
> for example.
>


Well, that's originally what I thought, that the bare repository carries 
all the data.  But (and I'm not sure how this came about), the more I 
was reading on using git the more it read like the bare repository ONLY 
housed the changes made.  For example, I have a technical document on 
how the structure of the database I'm designing.  If I edit the document 
and then push it to the bare repo, the ONLY thing in the bare repo is 
the delta of that document, not the delta AND the original document. 
Does that make sense?

In essence, it sounded to me like the bare repo required a copy of the 
original data in order for it to be used, since it only housed the 
deltas of the original, not the originals themselves.

In retrospect, it sounds a bit silly now, I suppose since it would be 
impossible to for someone new to pull a copy of the data down from the 
bare repo and have it be useful.  But, that's how I read the docs I had 
googled when first getting started with this project.

I hope that makes it a little easier to understand why I had the problem 
I was having.  Thanks a lot for the informative reply, and the patience 
to do so.


-- 

Mark Haney
Software Developer/Consultant
AB Emblem
markh@abemblem.com
Linux marius.homelinux 3.3.1-5.fc16.x86_64 GNU/Linux

      reply	other threads:[~2012-04-20 13:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-19 14:35 Help with repo management Mark Haney
2012-04-19 23:49 ` Andrew Ardill
2012-04-20 12:39   ` Mark Haney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F915913.10908@abemblem.com \
    --to=markh@abemblem.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.