On Tue, Oct 28, 2014 at 12:56 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Ronnie Sahlberg <sahlberg@xxxxxxxxxx> writes: >> >>> commit 0295e9cebc41020ee84da275549b164a8770ffba upstream. >>> >>> Change refs.c to use a single transaction to copy/rename both the refs and >>> its reflog. Since we are no longer using rename() to move the reflog file >>> we no longer need to disallow rename_ref for refs with a symlink for its >>> reflog so we can remove that test from the testsuite. >> >> Do you mean that we used to do a single rename(2) to move the entire >> logfile, but now you copy potentially thousands of reflog entries >> one by one? >> >> Hmmmm,... is that an improvement? I think so. It makes to code a lot simpler and more atomic. As a side effect it removes restrictions for symlink handling and eliminates the two renames colliding race. Though, a read and then rewrite thousands of reflog entries will be slower than a single rename() syscall. > > I see some value in "keep the original while creating a new one, > just in case we fail to fully recreate the new one so that we can > roll back with less programming effort". But still, we should be > able to copy the original to new without parsing and reformatting > each and every entry, no? Is renaming a branch with a long history is such a frequent or time critical event? 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 During the special rename case, we are deleting one ref and creating another. For cases such as m->m/m or the reverse we must delete the old file/directory before we can create the new one. The old rename code did this by renaming the file out to a common directory and then back to the new location. Which is fast (but a bit ...) The alternative is to read the old file into memory, delete it and then write the content back to the new location, which is kind of what the new code does. If this turns out to be a bottleneck we can change the io when writing the reflog entries to use fwrite(). Lets see if there is a problem first. regards ronnie sahlberg -- 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