From: Junio C Hamano <gitster@pobox.com>
To: Ronnie Sahlberg <sahlberg@google.com>
Cc: "git\@vger.kernel.org" <git@vger.kernel.org>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH 05/15] refs.c: update rename_ref to use a transaction
Date: Tue, 28 Oct 2014 14:12:49 -0700 [thread overview]
Message-ID: <xmqqh9ynkiem.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAL=YDWm05PyO07HbiOTiweh+3AEvXnbptbzoreLw-b9YUrm-Hg@mail.gmail.com> (Ronnie Sahlberg's message of "Tue, 28 Oct 2014 13:56:16 -0700")
Ronnie Sahlberg <sahlberg@google.com> 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?
next prev parent reply other threads:[~2014-10-28 21:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 20:36 [PATCH 00/15] ref-transaction-rename Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 01/15] refs.c: allow passing raw git_committer_info as email to _update_reflog Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 02/15] refs.c: return error instead of dying when locking fails during transaction Ronnie Sahlberg
2014-11-11 10:34 ` Jeff King
2014-11-11 15:42 ` Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 03/15] refs.c: use packed refs when deleting refs during a transaction Ronnie Sahlberg
2014-10-22 19:48 ` Junio C Hamano
2014-10-21 20:36 ` [PATCH 04/15] refs.c: use a stringlist for repack_without_refs Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 05/15] refs.c: update rename_ref to use a transaction Ronnie Sahlberg
2014-10-28 19:07 ` Junio C Hamano
2014-10-28 19:56 ` Junio C Hamano
2014-10-28 20:56 ` Ronnie Sahlberg
2014-10-28 21:12 ` Junio C Hamano [this message]
2014-10-29 17:18 ` Ronnie Sahlberg
2014-10-29 18:43 ` Junio C Hamano
2014-10-30 18:46 ` Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 06/15] refs.c: rollback the lockfile before we die() in repack_without_refs Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 07/15] refs.c: move reflog updates into its own function Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 08/15] refs.c: write updates to packed refs when a transaction has more than one ref Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 09/15] remote.c: use a transaction for deleting refs Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 10/15] refs.c: make repack_without_refs static Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 11/15] refs.c: make the *_packed_refs functions static Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 12/15] refs.c: replace the onerr argument in update_ref with a strbuf err Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 13/15] refs.c: make add_packed_ref return an error instead of calling die Ronnie Sahlberg
2014-10-21 20:36 ` [PATCH 14/15] refs.c: make lock_packed_refs take an err argument Ronnie Sahlberg
2014-10-21 20:37 ` [PATCH 15/15] refs.c: add an err argument to pack_refs Ronnie Sahlberg
2014-10-30 19:57 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh9ynkiem.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=sahlberg@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.