From: Ronnie Sahlberg <sahlberg@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>,
Michael Haggerty <mhagger@alum.mit.edu>
Subject: Re: [PATCH 07/31] refs.c: add a flag to allow reflog updates to truncate the log
Date: Mon, 19 May 2014 16:27:05 -0700 [thread overview]
Message-ID: <CAL=YDWn=t_+0Tt7--k1wAfUFXwTpsaEUDgYwdKbDPjmca5xdVA@mail.gmail.com> (raw)
In-Reply-To: <xmqqy4y18lol.fsf@gitster.dls.corp.google.com>
On Fri, May 16, 2014 at 2:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ronnie Sahlberg <sahlberg@google.com> writes:
>
>> Add a flag that allows us to truncate the reflog before we write the update.
>>
>> Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
>> ---
>
> Until we read the callers it is hard to see how such a feature is
> useful, though.
Shortly later in the series comes the update to builtin/reflog.c which
uses this feature.
Even later in the series I also use this in builtin/reflog.c to both
do the ref update as well as the corresponding reflog updates all in
one single transaction.
>
> (style) The two multi-line comments are formatted differently.
Fixed. Thanks.
>
>> refs.c | 12 ++++++++++--
>> refs.h | 4 +++-
>> 2 files changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/refs.c b/refs.c
>> index d8a1568..a8b583a 100644
>> --- a/refs.c
>> +++ b/refs.c
>> @@ -3608,7 +3608,11 @@ int transaction_commit(struct ref_transaction *transaction,
>> }
>> }
>>
>> - /* Update all reflog files */
>> + /* Update all reflog files
>> + We have already done all ref updates and deletes.
>> + There is not much we can do here if there are any reflog
>> + update errors, other than complain.
>> + */
>> for (i = 0; i < n; i++) {
>> struct ref_update *update = updates[i];
>>
>> @@ -3616,7 +3620,11 @@ int transaction_commit(struct ref_transaction *transaction,
>> continue;
>> if (update->reflog_fd == -1)
>> continue;
>> -
>> + if (update->flags & REFLOG_TRUNCATE)
>> + if (lseek(update->reflog_fd, 0, SEEK_SET) < 0 ||
>> + ftruncate(update->reflog_fd, 0)) {
>> + error("Could not truncate reflog");
>> + }
>
> The {} looks somewhat curious here. If you seeked to the beginning,
> and failed to truncate, do you still want to go on without "return"
> in front of the error()? Would that overwrite existing entries?
I have changed it to do this :
+ if (update->flags & REFLOG_TRUNCATE)
+ if (lseek(update->reflog_fd, 0, SEEK_SET) < 0 ||
+ ftruncate(update->reflog_fd, 0)) {
+ error("Could not truncate reflog: %s",
+ update->refname);
+ rollback_lock_file(&update->reflog_lock);
+ update->reflog_fd = -1;
+ }
At this point we have already committed all the changes to refs and
also performed all unlinks for refs we are deleting. So if things
start to go wrong here during the reflog updates it is too late to do
much more than complain.
>
>> if (log_ref_write_fd(update->reflog_fd, update->old_sha1,
>> update->new_sha1,
>> update->committer, update->msg)) {
>> diff --git a/refs.h b/refs.h
>> index 2e22a26..b1b97e7 100644
>> --- a/refs.h
>> +++ b/refs.h
>> @@ -269,8 +269,10 @@ int transaction_delete_sha1(struct ref_transaction *transaction,
>> const unsigned char *old_sha1,
>> int flags, int have_old, const char *msg);
>>
>> +#define REFLOG_TRUNCATE 0x01
>> /*
>> - * Append a reflog entry for refname.
>> + * Append a reflog entry for refname. If the REFLOG_TRUNCATE flag is set
>> + * this update will first truncate the reflog before writing the entry.
>> */
>> int transaction_update_reflog(struct ref_transaction *transaction,
>> const char *refname,
next prev parent reply other threads:[~2014-05-19 23:27 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 22:12 [PATCH 00/31] Finish implementing ref and reflog transactions Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 01/31] refs.c make ref_transaction_create a wrapper to ref_transaction_update Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 02/31] refs.c: make ref_transaction_delete a wrapper for ref_transaction_update Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 03/31] refs.c: rename the transaction functions Ronnie Sahlberg
2014-05-16 21:15 ` Junio C Hamano
2014-05-19 23:11 ` Ronnie Sahlberg
2014-05-19 23:25 ` Junio C Hamano
2014-05-14 22:13 ` [PATCH 04/31] refs.c: add a new update_type field to ref_update Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 05/31] refs.c: add a function to append a reflog entry to a fd Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 06/31] refs.c: add a transaction function to append a reflog entry Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 07/31] refs.c: add a flag to allow reflog updates to truncate the log Ronnie Sahlberg
2014-05-16 21:20 ` Junio C Hamano
2014-05-19 23:27 ` Ronnie Sahlberg [this message]
2014-05-14 22:13 ` [PATCH 08/31] refs.c: only write reflog update if msg is non-NULL Ronnie Sahlberg
2014-05-16 21:24 ` Junio C Hamano
2014-05-19 22:55 ` Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 09/31] refs.c: allow multiple reflog updates during a single transaction Ronnie Sahlberg
2014-05-16 21:35 ` Junio C Hamano
2014-05-16 22:01 ` Eric Sunshine
2014-05-19 22:58 ` Ronnie Sahlberg
2014-05-19 23:06 ` Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 10/31] reflog.c: use a reflog transaction when writing during expire Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 11/31] refs.c: null terminate the string in copy_msg Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 12/31] refs.c: track the refnames we are deleting in the transaction structure Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 13/31] refs.c: update the list of deleted refs during _update instead of _commit Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 14/31] refs.c: return error instead of dying when locking fails during transaction Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 15/31] refs.c: lock the ref during _update instead of during _commit Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 16/31] refs.c: add an error argument to create/delete/update just like commit Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 17/31] refs.c: make _update_reflog take an error argument Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 18/31] refs.c: return immediately from _commit if the transaction has an error Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 19/31] tests: move tests for -z update/delete/verify to after the ref is created Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 20/31] refs.c: check for lock conflicts already in _update Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 21/31] refs.c allow multiple updates of the same ref in a transaction Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 22/31] refs.c: release all remaining locks during transaction_free Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 23/31] reflog.c: use the existing transaction to also lock and update the ref Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 24/31] refs.c: make unlock_ref static Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 25/31] refs.c: make close_ref static Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 26/31] refs.c: make commit_ref static Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 27/31] refs.c: remove the function lock_any_ref_for_update Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 28/31] refs.c: make struct ref_lock private to refs.c Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 29/31] refs.c: allow passing raw git_committer_info as email to _update_reflog Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 30/31] refs.c: move ref_update and other definitions to earlier in the file Ronnie Sahlberg
2014-05-14 22:13 ` [PATCH 31/31] refs.c: use the transaction to manage the reflog in rename_refs Ronnie Sahlberg
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='CAL=YDWn=t_+0Tt7--k1wAfUFXwTpsaEUDgYwdKbDPjmca5xdVA@mail.gmail.com' \
--to=sahlberg@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mhagger@alum.mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).