Am 12.07.2013 19:40, schrieb Junio C Hamano:
> Johannes Sixt <j6t@xxxxxxxx> writes:
>
>> Am 12.07.2013 00:14, schrieb Junio C Hamano:
>>> Johannes Sixt <j6t@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html