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: Wed, 29 Oct 2014 11:43:09 -0700 [thread overview]
Message-ID: <xmqqtx2myawy.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAL=YDWkOZ29+ikXJUzhZqW8-Mk91Z_E1QCiXxT1HZ1oj04pk0w@mail.gmail.com> (Ronnie Sahlberg's message of "Wed, 29 Oct 2014 10:18:37 -0700")
Ronnie Sahlberg <sahlberg@google•com> writes:
> On Tue, Oct 28, 2014 at 2:12 PM, Junio C Hamano <gitster@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.
next prev parent reply other threads:[~2014-10-29 18:43 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
2014-10-29 17:18 ` Ronnie Sahlberg
2014-10-29 18:43 ` Junio C Hamano [this message]
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=xmqqtx2myawy.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jrnieder@gmail$(echo .)com \
--cc=sahlberg@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox