Subject: Re: [PATCH 6/9] pseudorefs: create and use pseudoref update and delete functions

From: David Turner <[email-masked]>
Date: Fri, 24 Jul 2015 16:17:15 -0400

On Fri, 2015-07-24 at 12:25 -0700, Junio C Hamano wrote:
> David Turner <[email-masked]> 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.