git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Brad King <brad.king@kitware.com>
Cc: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
	Vicent Marti <tanoku@gmail.com>,
	Johan Herland <johan@herland.net>,
	git@vger.kernel.org
Subject: Re: [PATCH 03/26] t1400: Pass a legitimate <newvalue> to update command
Date: Thu, 20 Mar 2014 18:01:05 +0100	[thread overview]
Message-ID: <532B1ED1.3090208@alum.mit.edu> (raw)
In-Reply-To: <531F82FE.9030305@kitware.com>

On 03/11/2014 10:41 PM, Brad King wrote:
> On Tue, Mar 11, 2014 at 4:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I may be misremembering things, but your first sentence quoted above
>> was exactly my reaction while reviewing the original change, and I
>> might have even raised that as an issue myself, saying something
>> like "consistency across values is more important than type-saving
>> in a machine format".
> 
> For reference, the original design discussion of the format was here:
> 
>  http://thread.gmane.org/gmane.comp.version-control.git/233842
> 
> I do not recall this issue being raised before, but now that it has
> been raised I fully agree:
> 
>  http://thread.gmane.org/gmane.comp.version-control.git/243754/focus=243862
> 
> In -z mode an empty <newvalue> should be treated as missing just as
> it is for <oldvalue>.  This is obvious now in hindsight and I wish I
> had realized this at the time.  Back then I went through a lot of
> iterations on the format and missed this simplification in the final
> version :(

It's not your fault; anybody could have reviewed your code at the time
(I most of all, because I have been so active in this area of the code).

> Moving forward:
> 
> The "create" command rejects a zero <newvalue> so the change in
> question for that command is merely the wording of the error message
> and there is no compatibility issue.
> 
> The "update" command supports a zero <newvalue> so that it can
> be used for all operations (create, update, delete, verify) with
> the proper combination of old and new values.  The change in question
> makes an empty <newvalue> an error where it was previously treated
> as zero.  (BTW, Michael, I do not see a test case for the new error
> in your series.  Something like the patch below should work.)
> 
>> I am not against deprecating and removing
>> the support for it in the longer term, though.
> 
> As I reported in my above-linked response, I'm not depending on
> the old behavior myself.  Also if one were to start seeing this
> error then generated input needs only trivial changes to avoid it.
> If we do want to preserve compatibility for others then perhaps an
> empty <newvalue> with -z should produce:
> 
>  warning: update $ref: missing <newvalue>, treating as zero

This last suggestion is what I am implementing for the re-roll (coming
shortly).  Thanks for the discussion.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

  reply	other threads:[~2014-03-20 17:01 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-10 12:46 [PATCH 00/26] Clean up update-refs --stdin and implement ref_transaction Michael Haggerty
2014-03-10 12:46 ` [PATCH 01/26] t1400: Fix name and expected result of one test Michael Haggerty
2014-03-10 12:46 ` [PATCH 02/26] t1400: Provide sensible input to the command Michael Haggerty
2014-03-10 12:46 ` [PATCH 03/26] t1400: Pass a legitimate <newvalue> to update command Michael Haggerty
2014-03-10 17:03   ` Brad King
2014-03-10 21:38     ` Michael Haggerty
2014-03-11 12:49       ` Brad King
2014-03-11 20:06       ` Junio C Hamano
2014-03-11 21:41         ` Brad King
2014-03-20 17:01           ` Michael Haggerty [this message]
2014-03-10 12:46 ` [PATCH 04/26] parse_arg(): Really test that argument is properly terminated Michael Haggerty
2014-03-10 12:46 ` [PATCH 05/26] t1400: Add some more tests involving quoted arguments Michael Haggerty
2014-03-10 13:53   ` Johan Herland
2014-03-10 12:46 ` [PATCH 06/26] refs.h: Rename the action_on_err constants Michael Haggerty
2014-03-10 12:46 ` [PATCH 07/26] update_refs(): Fix constness Michael Haggerty
2014-03-10 12:46 ` [PATCH 08/26] update-ref --stdin: Read the whole input at once Michael Haggerty
2014-03-10 12:46 ` [PATCH 09/26] parse_cmd_verify(): Copy old_sha1 instead of evaluating <oldvalue> twice Michael Haggerty
2014-03-10 12:46 ` [PATCH 10/26] update-ref.c: Extract a new function, parse_refname() Michael Haggerty
2014-03-10 12:46 ` [PATCH 11/26] update-ref --stdin: Improve error messages for invalid values Michael Haggerty
2014-03-10 12:46 ` [PATCH 12/26] update-ref --stdin: Make error messages more consistent Michael Haggerty
2014-03-10 12:46 ` [PATCH 13/26] update-ref --stdin: Simplify error messages for missing oldvalues Michael Haggerty
2014-03-10 17:08   ` Brad King
2014-03-10 17:12     ` Brad King
2014-03-10 12:46 ` [PATCH 14/26] update-ref.c: Extract a new function, parse_next_sha1() Michael Haggerty
2014-03-10 12:46 ` [PATCH 15/26] update-ref --stdin: Improve the error message for unexpected EOF Michael Haggerty
2014-03-10 12:46 ` [PATCH 16/26] update-ref --stdin: Harmonize error messages Michael Haggerty
2014-03-10 12:46 ` [PATCH 17/26] refs: Add a concept of a reference transaction Michael Haggerty
2014-03-10 12:46 ` [PATCH 18/26] update-ref --stdin: Reimplement using reference transactions Michael Haggerty
2014-03-10 12:46 ` [PATCH 19/26] refs: Remove API function update_refs() Michael Haggerty
2014-03-10 12:46 ` [PATCH 20/26] struct ref_update: Rename field "ref_name" to "refname" Michael Haggerty
2014-03-10 12:46 ` [PATCH 21/26] struct ref_update: Store refname as a FLEX_ARRAY Michael Haggerty
2014-03-10 12:46 ` [PATCH 22/26] commit_ref_transaction(): Introduce temporary variables Michael Haggerty
2014-03-10 12:46 ` [PATCH 23/26] struct ref_update: Add a lock member Michael Haggerty
2014-03-10 12:46 ` [PATCH 24/26] struct ref_update: Add type field Michael Haggerty
2014-03-10 12:46 ` [PATCH 25/26] commit_ref_transaction(): Also free the ref_transaction Michael Haggerty
2014-03-10 12:46 ` [PATCH 26/26] commit_ref_transaction(): Work with transaction->updates in place Michael Haggerty
2014-03-10 17:44 ` [PATCH 00/26] Clean up update-refs --stdin and implement ref_transaction Brad King
2014-03-10 21:46   ` 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

  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=532B1ED1.3090208@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=brad.king@kitware.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johan@herland.net \
    --cc=peff@peff.net \
    --cc=tanoku@gmail.com \
    /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).