From: David Turner <dturner@twopensource.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, mhagger@alum.mit.edu
Subject: Re: [PATCH 6/9] pseudorefs: create and use pseudoref update and delete functions
Date: Fri, 24 Jul 2015 16:17:15 -0400 [thread overview]
Message-ID: <1437769035.1141.16.camel@twopensource.com> (raw)
In-Reply-To: <xmqqbnf1mk72.fsf@gitster.dls.corp.google.com>
On Fri, 2015-07-24 at 12:25 -0700, Junio C Hamano wrote:
> David Turner <dturner@twopensource.com> writes:
>
> > Pseudorefs should not be updated through the ref API, because the ref
> > API is for real refs. Instead, use a dedicated pseudoref API.
> >
> > This patch changes writes to CHERRY_PICK_HEAD, REVERT_HEAD, and ORIG_HEAD.
>
> This feels somewhat backwards, and it makes me wonder if it is a
> better approach to teach update_ref() about the naming rules, so
> that the callers do not have to say the same thing twice "This is
> not a ref and I am giving all-caps name, by the way I am also not
> calling update_ref() because that is only for real refs".
Do you mean teach update_ref to call write_pseudoref for pseudorefs and
call the normal codepath for regular refs? I considered this, but I was
worried about ref transactions. It would be odd if
ref_transaction_update worked differently than update_ref. And I didn't
want to deal with making pseudoref updates transactional, because then
alternate backends would have to maintain multiple transactions, which
turned out to be a giant hassle.
But maybe it's OK if update_ref operates differently than
ref_transaction_update? (and same for
delete_ref/ref_transaction_delete). After all, people who call
update_ref don't really care about the transactional semantics.
next prev parent reply other threads:[~2015-07-24 20:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-24 4:45 [PATCH/RFC 0/9] Pseudorefs David Turner
2015-07-24 4:45 ` [PATCH 1/9] refs: Introduce pseudoref and per-worktree ref concepts David Turner
2015-07-24 7:34 ` Eric Sunshine
2015-07-24 19:20 ` Junio C Hamano
2015-07-24 20:13 ` David Turner
2015-07-24 20:44 ` Junio C Hamano
2015-07-24 19:52 ` Philip Oakley
2015-07-24 20:14 ` David Turner
2015-07-24 4:45 ` [PATCH 2/9] notes: replace pseudorefs with real refs David Turner
2015-07-24 4:45 ` [PATCH 3/9] bisect: do not use update-ref for BISECT_HEAD David Turner
2015-07-24 4:45 ` [PATCH 4/9] tests: treat FETCH_HEAD as a pseudoref David Turner
2015-07-24 4:45 ` [PATCH 5/9] tests: use --create-reflog option to git update-ref David Turner
2015-07-24 4:45 ` [PATCH 6/9] pseudorefs: create and use pseudoref update and delete functions David Turner
2015-07-24 19:25 ` Junio C Hamano
2015-07-24 20:17 ` David Turner [this message]
2015-07-24 20:53 ` Junio C Hamano
2015-07-24 4:45 ` [PATCH 7/9] am/rebase: update pseudorefs by writing files David Turner
2015-07-24 4:45 ` [PATCH 8/9] rebase: use write_pseudoref David Turner
2015-07-24 4:45 ` [PATCH 9/9] refs: forbid pseudoref updates through ref update API David Turner
2015-08-02 22:48 ` [PATCH/RFC 0/9] Pseudorefs Michael Haggerty
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=1437769035.1141.16.camel@twopensource.com \
--to=dturner@twopensource.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 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.