Re: [PATCH 7/7] push: document --lockref

[Junio C Hamano <gitster@pobox.com>]

Johannes Sixt <j6t@kdbg.org> writes:

> I am suggesting that +refspec would *not* override the match/mismatch
> safety, but --force would.

OK.

I earlier did not read from your message that you wanted to change
"+refspec" to mean "allow non-ff push", so the two entries in your
table:

>                        ff   noff     ff      noff
>                       match match mismatch mismatch
>
> --lockref +refspec     ok    ok    denied   denied
> --lockref  refspec     ok  denied  denied   denied

did not make sense to me.  If you are making "+refspec" to mean
"--allow-no-ff refspec", then above is at least internally
consistent.

>> Let's look at noff/match case.  That is the only interesting one.
>> 
>> This should fail:
>> 
>> 	git push topic
>> 
>> due to no-ff.
>
> Yes.
>
>> Your table above makes this fail:
>> 
>>         git push --lockref topic
>> 
>> and the user has to force it,
>
> Of course.
>
>> like this?
>> 
>> 	git push --lockref --force topic ;# or alternatively
>>         git push --lockref +topic
>> 
>> Why is it even necessary?

> Because it is no-ff. How do you achieve the push today (without
> --lockref)? You use one of these two options. It does not change with
> --lockref.

But by going that route, you are making --lockref _less_ useful, no?

"git push topic" in no-ff/match case fails as it should.  The whole
purpose of "--lockref" is to make this case easier and safer than
the today's system, where the anything-goes "--force" is the only
way to make this push.  We want to give a user who

 - rebased the topic, and

 - knows where the topic at the remote should be

a way to say "I know I am pushing a no-ff, and I want to make sure
the current value is this" in order to avoid losing somebody else's
work queued on top of the topic at the remote while he was rebasing.

You _CAN_ introduce a new --allow-no-ff at the same time and fail a
no-ff/match push:

	git push --lockref topic

and then allow it back with:

	git push --lockref --allow-no-ff topic
	git push --lockref +topic ;# +topic is now --allow-no-ff topic

but why _SHOULD_ we?  As soon as the user _says_ --lockref, the user
is telling us he is pushing a no-ff.  If that is not the case, the
user can push without --lockref in the first place.

The only potential thing you are gaining with such a change is that
you are allowing people to say "this will fast-forward _and_ the I
know the current value; if either of these two assumptions is
violated, please fail this push".

If "--lockref" automatically implies "--allow-no-ff" (the design in
the reposted patch), you cannot express that combination.  But once
you use "--lockref" in such a situation , for the push to succeed,
you know that the push replaces not just _any_ ancestor of what you
are pushing, but replaces the exact current value.  So I do not think
your implicit introduction of --allow-no-ff via redefining the
semantics of the plus prefix is not adding much value (if any),
while making the common case less easy to use.

> No; --lockref only adds the check that the destination is at the
> expected revision, but does *NOT* override the no-ff check.

You _could_ do it in that way, but that is less useful.