Ronnie Sahlberg <sahlb...@google.com> writes: > On Tue, Oct 28, 2014 at 2:12 PM, Junio C Hamano <gits...@pobox.com> wrote: > >> More importantly, when you know that the end result you want to see >> is that the old and new log files are bit-for-bit identical, and if >> not there is some bug in either parsing or formatting, why parse the >> old and reformat into the new? What would happen when there were >> malformed entries in the old that makes your parsing fail? >> > > Fair enough. I will change it to ONLY use a transaction for the actual > ref update and keep using rename() for the reflog handling. > Only real change I will do for the reflog handling is to change the > temporary file name used to be less collission prone if there are two > renames happening at the same time > so that they don't destroy each others reflogs.
I think it is a good idea to make renaming the entire reflog a logical element of transaction (as you mentioned in our private discussion) to allow different backends implement in their best efficient & robust way. And for filesystem-backed backends, I actually think "keep the original until we know we do not have to roll back", that follows the same pattern for the other transactional updates, is a good implementation of that "best efficient & robust way", compared to the original "just rename it". It frees us from having to be worried about what happens if we cannot rename it back. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
