Re: RFC: --force-with-lease default behaviour

[Junio C Hamano <gitster@pobox.com>]

"G. Sylvie Davies" <sylvie@bit-booster.com> writes:

> I wonder if there's anything one could do to help those who type "git
> fetch" and still want to enjoy "--force-with-lease"...

The entire idea behind "force-with-lease" is that you plan to later
force update the tip of a branch at the remote to replace the commit
that used to be at the tip at some point, that you do not want other
people to have their own work on that branch that will be lost by
your later force-pushing, yet you cannot "lock" a branch at the
remote repository remotely because that goes against the distributed
nature of the development.  Instead of locking others out, forcing
others to wait and sit idle while you complete the material to be
force-pushed (which may never happen), you base your work on one
state of the remote branch, and make sure the remote branch hasn't
advanced in the meantime (or you redo your work)---the cost of the
extra work due to your planned force-pushing is beared by you, not
by others.

There however is no place in Git where you explicitly declare "this
is where I start working on producing a new commit.  That commit
will replace this state and will not fast-forward from it." and
store it locally.  The "--force-with-lease" was designed to take
that information from the command line, expecting that the script
that drives it does something like

	#!/bin/sh
	LEASE=$(git rev-parse --verify @{u})
	# do whatever that requires non-fast-forward push
	git commit --amend ...
	... maybe more ...
	# finally push it out
	git push --force-with-lease $LEASE ...

Lazy people decided that as long as they promise to themselves that
they are not going to do anything to cause @{u} to move, they can
use it as a lazy-man's approximate.  Perhaps that was a misguided
attempt to add convenience.

A possible answer to your wordering may be to deprecate the
defaulting to @{u} and always require the expected commit to be
specified explicitly.