Johannes Sixt [off-list ref] 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.
I am not opposed if your proposal were to introduce a new syntax
element that calls for this new feature, e.g.
[remote "ko"]
url = kernel.org:/pub/scm/git/git.git
push = *pu
fetch = +refs/heads/*:refs/remotes/ko/*
but changing what "+" means to something new will simply not fly.
Am 12.07.2013 00:14, schrieb Junio C Hamano:
Johannes Sixt [off-list ref] writes:
quoted
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.
To achieve any safety at all for these push-only refs, you have to be
very explicit by saying --lockref=pu:$myoldpu
--lockref=master:$myoldmaster etc, and what is wrong if in this case
--lockref semantics are applied, but only pu is allowed to be no-ff?
I am not opposed if your proposal were to introduce a new syntax
element that calls for this new feature, e.g.
[remote "ko"]
url = kernel.org:/pub/scm/git/git.git
push = *pu
fetch = +refs/heads/*:refs/remotes/ko/*
but changing what "+" means to something new will simply not fly.
I still do not see why we need two different kinds of ways to spell the
same strong kind of override (--force and +refspec) under the presence
of --lockref, and why we need a third one (--allow-no-ff) to give a
weaker kind of override (that makes sense only when --lockref was given
in the first place).
-- Hannes