git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Brad King <brad.king@kitware.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
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: Tue, 11 Mar 2014 17:41:18 -0400	[thread overview]
Message-ID: <531F82FE.9030305@kitware.com> (raw)
In-Reply-To: <xmqqa9cwpkiw.fsf@gitster.dls.corp.google.com>

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 :(

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

Then after a few releases it can be switched to an error.

Thanks,
-Brad


diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 3cc5c66..1e9fe7c 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -730,6 +730,12 @@ test_expect_success 'stdin -z fails update with bad ref name' '
 	grep "fatal: invalid ref format: ~a" err
 '

+test_expect_success 'stdin -z fails update with empty new value' '
+	printf $F "update $a" "" >stdin &&
+	test_must_fail git update-ref -z --stdin <stdin 2>err &&
+	grep "fatal: update $a: missing <newvalue>" err
+'
+
 test_expect_success 'stdin -z fails update with no new value' '
 	printf $F "update $a" >stdin &&
 	test_must_fail git update-ref -z --stdin <stdin 2>err &&
-- 
1.8.5.2

  reply	other threads:[~2014-03-11 21:40 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 [this message]
2014-03-20 17:01           ` Michael Haggerty
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=531F82FE.9030305@kitware.com \
    --to=brad.king@kitware.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johan@herland.net \
    --cc=mhagger@alum.mit.edu \
    --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).