Hi, On Mon, 12 May 2008, Heikki Orsila wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
