Ronnie Sahlberg [off-list ref] writes:
I timed a git branch -m for a branch with ~2400 log entries and it
takes neglible time :
real 0m0.008s
user 0m0.000s
sys 0m0.007s
I really hate this line of reasoning. Small things tend to add up.
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?
On Tue, Oct 28, 2014 at 2:12 PM, Junio C Hamano [off-list ref] wrote:
Ronnie Sahlberg [off-list ref] writes:
quoted
I timed a git branch -m for a branch with ~2400 log entries and it
takes neglible time :
real 0m0.008s
user 0m0.000s
sys 0m0.007s
I really hate this line of reasoning. Small things tend to add up.
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.