On Mon, 12 May 2008, Junio C Hamano wrote: > Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > > I think suggestions from old timers on this thread to first "git fetch" is > to handle that concern. Yeah, "git fetch" is the right solution (although it's a pain to do a backup of "every repo under <path>" or "every repo anywhere under <path>" that way, which I suspect of being the real issue). I just wanted to get a note into this thread of what problems using rsync can and cannot have, since it's different (both more and less reliable) from what the original poster asked about. > It may not get the commit that is being created simultaneously when such > a fetch to backup repository is running (but that will be backed up > during the next round), but at least the contents of the backup > repository would be self contained and correct. And simultaneous commit isn't really an issue; nothing will back up work you do right after the backup runs, and users can't tell whether they did the commit before or after the backup if it's close. -Daniel *This .sig left intentionally blank* -- 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
