Hi, On Sun, 18 Jan 2009, Ray Chuan wrote: > On Sun, Jan 18, 2009 at 12:48 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > "Ray Chuan" <rctay89@xxxxxxxxx> writes: > > > >> A concern raised was repository corruption in the event of failure > >> during PUT. "put && move" won't afford any more protection than using > >> simply "put", since info/refs is not updated if a PUT fails, so there > >> is no cause for concern. > > > > That's a completely bogus reasoning. Normal operation inside the > > repository that was pushed into won't look at info/refs at all. > > i mentioned this "repository corruption" issue as it was raised > previously by Johannes (towards the bottom): > > http://article.gmane.org/gmane.comp.version-control.git/106031 ,.. and Junio just raised a new concern. The repository as it is on the server could very well be served by other means, i.e. git:// and rsync://, and there could be cron jobs and interactive Git sessions trying to work with it. The point is: the repository inside the document root of the web server is still a valid repository. And the assumption is that whenever you have a file that looks like a valid object/pack inside a valid repository, that it does not need replacing. So even when optimizing the uncommon (HTTP push is 2nd class citizen), we have to keep the common workflow intact (1st class citizens _are_ push by file system, ssh or git://). Which unfortunately means that put && move must stay. The same reasoning explains why http-push has to ignore the info/refs file when looking for common refs, BTW. 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
