RFC: --force-with-lease default behaviour

Right now the default variant does this:

The problem is people sometimes run "git fetch". And so "git push --force-with-lease" is going to do the push even if the local version is stale.

Instead I think the default behavior should require that the remote ref's current value be equal to the merge-base of the local-branch and remote-tracking-branch.

Here's an example (password is "test" for the push):

git clone http://test@vm.bit-booster.com/bitbucket/scm/bb/a.git cd a git checkout bugfix/TKT-123 git reset --hard HEAD~1 (to simulate situation where local is stale, but remote is up to date)

At this point "git push --force-with-lease" is going to work. But I think it shouldn't. (Note: I use push.default = simple).

Here's how I think it should work:

git push --force-with-lease=bugfix/TKT-123:$(git merge-base HEAD
origin/bugfix/TKT-123)
To http://vm.bit-booster.com/bitbucket/scm/bb/a.git
 ! [rejected]        bugfix/TKT-123 -> bugfix/TKT-123 (stale info)

For now I'm happy with this alias:

git config --global alias.please '!sh -c "git push --force-with-lease=$(git rev-parse --abbrev-ref HEAD):$(git merge-base HEAD @{u})"'

But I'd like to put together a patch if people are interested in a tweak like this to the --force-with-lease default behaviour. I haven't written much C in my life, but thought this might make a good force-myself-to-learn-C exercise.

- Sylvie Davies

ps. I never thought about the fetch problem with --force-with-lease until reading https://developer.atlassian.com/blog/2015/04/force-with-lease/ and https://buddyreno.me/git-please-a182f28efeb5#.s291gh5jn , so thanks to them!

On Wed, Jan 4, 2017 at 6:34 PM, G. Sylvie Davies <sylvie@bit-booster.com> wrote:

Nevermind! I realize this essentially removes the "--force" and turns it into the original non-forced "fast-forwardable" only style push. [BLUSH!]

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

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

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.