On 9/5/2013 5:23 PM, Junio C Hamano wrote:
> Brad King <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
