Johannes Sixt <j6t@xxxxxxxx> writes:
> Am 14.07.2013 21:17, schrieb Junio C Hamano:
>> Johannes Sixt <j6t@xxxxxxxx> writes:
>>> I actually think that by implying allow-no-ff in --lockref, you are
>>> hurting users who have configured a push refspec without a + prefix:
>>> They suddenly do not get the push denied when it is not a fast-forward
>>> anymore.
>>
>> Of course, that is why you should not use --lockref when you do not
>> have to. It is a tool to loosen "must fast-forward" in a more
>> controlled way than the traditional "--force".
>
> Sorry, IMO, this goes into a totally wrong direction, in particular, I
> think that this is going to close to door to make --lockref the default
> some day in a way that helps everyone.
I would presume that you would force that "reverse tracking"
short-hand as the expected value, as "default" will not have other
sources of information.
I think the use of "reverse tracking" is way overrated. It is
probably the only default value that we could use, if the user is
too lazy not to specify it, but I do not think it is particularly a
sensible or safe default.
The following does not discuss "should --lockref automatically
disable the 'must fast-forward' check?". The problem highlighted is
the same, regardless of the answer to that question.
After rebasing beyond what is already published, you try the
"lockref" push, e.g. (we assume you work on master and push back to
update master at your origin):
$ git fetch
$ git rebase -i @{u}~4 ;# rebase beyond what is there
$ git push ;# of course this will not fast-forward
$ git push --lockref
... or with your "must-fast-forward is independent"
$ git push --lockref origin +master
... or also with your "--lockref is default"
$ git push origin +master
If somebody else pushed while you are working on the rebase, the
last step (one of the above push) will fail due to stale
expectation. What now?
The user would want to keep the updated tip, so the first thing that
happens will always be
$ git fetch
$ git log ..@{u} ;# what will we be losing?
The right thing to do at this point is to rebase your 'master' again
on top of @{u}
$ git rebase -i @{u}
before attempting to push back again. If you do that, then you can
do another "lockref" push.
But the thing is, a novice who does not know what he is doing will
likely to do this:
$ git push --lockref
... or with your "must-fast-forward is independent"
$ git push --lockref origin +master
... or also with your "--lockref is default"
$ git push origin +master
... rejected due to stale expectation
$ git fetch
You just have updated the lockref base, so if you did, without doing
anything else,
$ git push origin +master
then you will lose the updated contents.
The conclusion? It does not make sense to make "lockref" the
default.
The --lockref mechanism is necessary _only_ when you want to break
the usual "must fast-forward" safety, and the user needs to be made
very aware of what he is doing. Making it default and making it
appear easy to invoke with a single "+", is totally going in a wrong
direction. Besides, by making it the default and turning "+" into
"only defeat 'must fast-forward", you will break existing setting of
people who have "remote.*.push = +ref" configured, without having a
remote-tracking for that ref.
So it will not happen; "lockref" will not be on by default, even if
it is made independent of "must fast-forward".
--
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