git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: David Turner <dturner@twopensource.com>
Cc: git@vger.kernel.org, mhagger@alum.mit.edu
Subject: Re: [PATCH 5/6] git-reflog: add create and exists functions
Date: Thu, 25 Jun 2015 10:18:09 -0700	[thread overview]
Message-ID: <xmqqioabzoz2.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1435173388-8346-6-git-send-email-dturner@twopensource.com> (David Turner's message of "Wed, 24 Jun 2015 15:16:27 -0400")

David Turner <dturner@twopensource.com> writes:

> These are necessary because ref backends manage reflogs.

Because?

	Because with core.logAllRefUpdates set to false, creating or
        updating a ref would not log what is done to it, unless a
        reflog already exists for the ref.  There are cases where
        we always want to have a reflog for a ref (e.g. refs/stash)
        regardless of the value of core.logAllRefUpdates, and we
        need a way to ensure that a reflog for a ref exists.
        "reflog create" is the way to do so.

	Also we need to be able to tell if a reflog for a ref
	exists, and "reflog exists" is the way to do so.

Now, going back to 4/6, I think create_reflog() function as an
external API has a few problems.

 * Its name does not tell us what should happen when a reflog
   already exists for the refname the caller asked to "create"
   reflog for.  I understand that this only makes sure it exists and
   does not destroy existing one.  Its old name, log_ref_setup(),
   did not have this problem, but now it does.

 * Its second parameter that is a strbuf is used only internally
   from within log_ref_write_1(); all the external callers do not
   look at it and they are forced to strbuf_init() it before calling
   the function and to strbuf_release() after the function returns.

Oh, also 4/6 incorrectly says that log_ref_write() is renamed to
create_reflog(), but it was log_ref_setup() that was renamed.

I think what 4/6 should have done in order to make the guts of what
log_ref_setup() does available as a more useful external API is to

 * keep log_ref_setup() as-is, make it static to refs.c, and have
   the internal caller that cares about the strbuf (i.e. the path
   to the log file) call that; and

 * Add a thin-wrapper for callers that do not care about the path to
   the log file, e.g.

	int vivify_reflog(const char *refname, struct strbuf *err)
	{
		int ret;
		struct strbuf sb = STRBUF_INIT;

                ret = log_ref_setup(refname, &sb, err);
                strbuf_release(&sb);
                return ret;
	}

Hmm?
    

  reply	other threads:[~2015-06-25 17:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-24 19:16 [PATCH 0/6] refs backend preamble David Turner
2015-06-24 19:16 ` [PATCH 1/6] refs.c: add an err argument to log_ref_setup David Turner
2015-06-25 16:15   ` Junio C Hamano
2015-06-24 19:16 ` [PATCH 2/6] cherry-pick: Use refs infrastructure for CHERRY_PICK_HEAD David Turner
2015-06-25 16:41   ` Junio C Hamano
2015-06-24 19:16 ` [PATCH 3/6] bisect: use refs infrastructure for BISECT_START David Turner
2015-06-25 16:52   ` Junio C Hamano
2015-06-25 20:29     ` David Turner
2015-06-24 19:16 ` [PATCH 4/6] refs: replace log_ref_write with create_reflog David Turner
2015-06-25 16:54   ` Junio C Hamano
2015-06-24 19:16 ` [PATCH 5/6] git-reflog: add create and exists functions David Turner
2015-06-25 17:18   ` Junio C Hamano [this message]
2015-06-25 18:35     ` Junio C Hamano
2015-06-25 20:31       ` David Turner
2015-06-24 19:16 ` [PATCH 6/6] git-stash: use git-reflog instead of creating files David Turner
2015-06-25 13:19 ` [PATCH 0/6] refs backend preamble 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqioabzoz2.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=dturner@twopensource.com \
    --cc=git@vger.kernel.org \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).