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

Johannes Sixt <j6t@kdbg.org> writes:

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".