Hi,

On Mon, 12 May 2008, Heikki Orsila wrote:

quoted text
> On Mon, May 12, 2008 at 06:07:28PM +0100, Johannes Schindelin wrote:
> 
> > On Mon, 12 May 2008, Heikki Orsila wrote:
> > 
> > > On Mon, May 12, 2008 at 04:08:21PM +0100, Johannes Schindelin wrote:
> > > > No, rsync is particularly dumb in that respect.  The safest thing 
> > > > would be to back up the reflogs first (e.g. with rsync), then 
> > > > repack and then clone (the clone will transmit the objects 
> > > > referenced by the reflogs, too).  Note: the same holds _not_ true 
> > > > for a simple fetch.
> > > > 
> > > > But then, you usually do not want to back up reflogs anyway, since 
> > > > they are purely local and not visible to anybody else.
> > > 
> > > Is there a simple and efficient mechanism for incremental backups?
> > 
> > Umm.  "git fetch"?
> > 
> > Like I said, it does not get the reflogs, but if you want to back up a 
> > repository, the safest is to clone once, and fetch later.  Or you 
> > could set up a remote with the --mirror option, if you want to 
> > preserve the refs' namespaces.
> 
> Preferably some solution that does not require too much understanding of 
> Git internals so that admins will actually use it, instead of hacking 
> their own inefficient backup scripts.
> 
> Could someone please write a "git-backup" script?-)

Heikki, why don't you just go with the "git fetch" approach I described?  
We do not need "git backup" when "git fetch" does already what you want.

Ciao,
Dscho

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