On 9/5/2013 5:23 PM, Junio C Hamano wrote:
> Brad King <brad.k...@kitware.com> writes:
>>      create SP <ref> NUL <newvalue> NUL
>>      update SP <ref> NUL <newvalue> NUL [<oldvalue>] NUL
> 
> That SP in '-z' format looks strange.  Was there a reason why NUL
> was inappropriate?

The precedent I saw in the -z survey I posted is that NUL is used
to terminate fields that can contain arbitrary text but otherwise
SP or TAB is still used to terminate simple fields.  I recall no
cases that use NUL after fields that only contain simple values.

>> option::
>>      Specify an option to take effect for following commands.
> 
> This last one is somewhat peculiar, especially because it says
> "following command*s*".
> 
> How would I request to update refs HEAD and next in an all-or-none
> fashion, while applying 'no-deref' only to HEAD but not next?

You're right.  It will be simpler for clients to generate each
sequence of options followed by a <ref> command without worrying
about options possibly generated for preceding <ref>s.  So:

option::
        Modify behavior of the next command naming a <ref>.
        The only valid option is `no-deref` to avoid dereferencing
        a symbolic ref.

> When I said "create or update" in the message you are responding to,
> I did not mean that we should have two separate commands.

The nice thing about "create" is that it implies oldvalue=zero, just
as "delete" implies newvalue=zero.  The symmetry feels clean.  Also,
in -z mode we need to treat an empty string <oldvalue> as missing
rather than zero.  The only way to specify create with the "update"
command is with literal 40 "0" as <oldvalue>.

> The regular command line does create-or-update; if it exists already,
> it is an update, and if it does not, it is a create.

The proposed update command can be used for create, update, delete,
or verify with proper arguments and use of 40 "0".  The other <ref>
commands are for convenience, shorter input, and statement of intent.

>       create-or-update-no-deref <ref> <newvalue> [<oldvalue>]
>         delete-no-deref <ref> [<oldvalue>]
> 
> Also how would one set the reflog message for the proposed update?

This is why I proposed a separate option command.  It can be used
both for no-deref and for other options we want to add later e.g.

  option SP message SP <reason> LF

and with -z:

  option SP message SP <reason> NUL

For now I think it is sufficient for the -m <reason> command-line
option to set the same message for all updates.  The option command
leaves room to add a per-ref message later.

BTW, the reasons I propose message as an option rather than its own
command are:

* It is simpler to document the reach of the one option command
  (affects next <ref>) in one place rather than separately for
  each option-like command.

* It reduces the number of commands that do not take a <ref>.

-Brad
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to