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

From: Johannes Sixt <j6t@kdbg.org>
Date: Jul 12, 2013, 20:00 UTC
Message-ID: <51E0605E.9020902@kdbg.org>
In-Reply-To: <7vli5bllsd.fsf@alter.siamese.dyndns.org>

Am 12.07.2013 19:40, schrieb Junio C Hamano:

Show 33 quoted lines

> Johannes Sixt <j6t@kdbg.org> writes:
> 
>> Am 12.07.2013 00:14, schrieb Junio C Hamano:
>>> Johannes Sixt <j6t@kdbg.org> writes:
>>>
>>>> Again: Why not just define +refspec as the way to achieve this check?
>>>
>>> What justification do we have to break existing people's
>>> configuration that says something like:
>>>
>>> 	[remote "ko"]
>>> 		url = kernel.org:/pub/scm/git/git.git
>>>                 push = master
>>>                 push = next
>>>                 push = +pu
>>>                 push = maint
>>>
>>> by adding a _new_ requirement they may not be able to satisify?
>>> Notice that the above is a typical "push only" publishing point,
>>> where you do not need any remote tracking branches.
>>
>> Why would it break? When you do not specify --lockref, there is no
>> change whatsoever.
> 
> I thought your suggestion "Why not just define +pu as the way to
> achieve _THIS_ check?" was to make +pu to mean
> 
> 	git push ko --lockref pu
> 
> which would mean "check refs/remotes/ko/pu and make sure the remote
> side still is at that commit".
> 
> If that is not what you meant, please clarify what _THIS_ is.

We have three independent options that the user can choose in any combination:

 o --force given or not;

 o --lockref semantics enabled or not;

 o refspec with or without +;

and these two orthogonal preconditions of the push

 o push is fast-forward or it is not ("ff", "noff");

 o the branch at the remote is at the expected rev or it is not
   ("match", "mismatch").

Here is a table with the expected outcome. "ok" means that the push is allowed(*), "fail" means that the push is denied. (Four more lines with --force are omitted because they have "ok" in all spots.)

                       ff   noff     ff      noff
                      match match mismatch mismatch

--lockref +refspec     ok    ok    denied   denied
--lockref  refspec     ok  denied  denied   denied
          +refspec     ok    ok      ok       ok
           refspec     ok  denied    ok     denied

Notice that without --lockref semantics enabled, +refspec and refspec keep the current behavior.

(*) As we are talking only about the client-side of the push here, I'm saying "allowed" instead of "succeeds" because the server can have additional restrictions that can make the push fail.

-- Hannes