{"thread":{"id":"44814","subject":"RFC: --force-with-lease default behaviour","startedAt":"2017-01-05T02:35:37Z","lastAt":"2017-01-07T21:04:22Z","messageCount":3,"participants":["G. Sylvie Davies","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"308812","messageId":"CAAj3zPz-jMVoxNTRZ0iR1ZPTFh873gEo33QjynBE1vaHsMmg3A@mail.gmail.com","threadId":"44814","inReplyTo":null,"subject":"RFC: --force-with-lease default behaviour","fromName":"G. Sylvie Davies","fromEmail":"sylvie@bit-booster.com","sentAt":"2017-01-05T02:34:18Z","receivedAt":"2017-01-05T02:35:37Z","isPatch":false,"sender":{"key":"sylvie@bit-booster.com","avatar":"https://gravatar.com/avatar/eb5bda7d3fb1e3361252bbf100d1f355ffe9ff8d8b559a08e4c7bc17d6f949d5?d=mp&s=160"},"body":"Right now the default variant does this:\n\n> --force-with-lease alone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have for them.\n\nThe problem is people sometimes run \"git fetch\".   And so \"git push\n--force-with-lease\" is going to do the push even if the local version\nis stale.\n\nInstead I think the default behavior should require that the remote\nref's current value be equal to the merge-base of the local-branch and\nremote-tracking-branch.\n\nHere's an example (password is \"test\" for the push):\n\ngit clone http://test@vm.bit-booster.com/bitbucket/scm/bb/a.git\ncd a\ngit checkout bugfix/TKT-123\ngit reset --hard HEAD~1   (to simulate situation where local is stale,\nbut remote is up to date)\n\nAt this point \"git push --force-with-lease\" is going to work.   But I\nthink it shouldn't.   (Note: I use push.default = simple).\n\nHere's how I think it should work:\n\ngit push --force-with-lease=bugfix/TKT-123:$(git merge-base HEAD\norigin/bugfix/TKT-123)\nTo http://vm.bit-booster.com/bitbucket/scm/bb/a.git\n ! [rejected]        bugfix/TKT-123 -> bugfix/TKT-123 (stale info)\n\n\nFor now I'm happy with this alias:\n\ngit config --global alias.please '!sh -c \"git push\n--force-with-lease=$(git rev-parse --abbrev-ref HEAD):$(git merge-base\nHEAD @{u})\"'\n\nBut I'd like to put together a patch if people are interested in a\ntweak like this to the --force-with-lease default behaviour.  I\nhaven't written much C in my life, but thought this might make a good\nforce-myself-to-learn-C exercise.\n\n\n- Sylvie Davies\n\nps.  I never thought about the fetch problem with --force-with-lease\nuntil reading https://developer.atlassian.com/blog/2015/04/force-with-lease/\nand https://buddyreno.me/git-please-a182f28efeb5#.s291gh5jn , so\nthanks to them!\n"},{"id":"308813","messageId":"CAAj3zPx4uMXhV7t86Cnn8SgmpXb2SGththYN7sHetOqL_JosMg@mail.gmail.com","threadId":"44814","inReplyTo":"CAAj3zPz-jMVoxNTRZ0iR1ZPTFh873gEo33QjynBE1vaHsMmg3A@mail.gmail.com","subject":"Re: RFC: --force-with-lease default behaviour","fromName":"G. Sylvie Davies","fromEmail":"sylvie@bit-booster.com","sentAt":"2017-01-05T06:52:44Z","receivedAt":"2017-01-05T06:54:16Z","isPatch":false,"sender":{"key":"sylvie@bit-booster.com","avatar":"https://gravatar.com/avatar/eb5bda7d3fb1e3361252bbf100d1f355ffe9ff8d8b559a08e4c7bc17d6f949d5?d=mp&s=160"},"body":"On Wed, Jan 4, 2017 at 6:34 PM, G. Sylvie Davies <sylvie@bit-booster.com> wrote:\n> Right now the default variant does this:\n>\n>> --force-with-lease alone, without specifying the details, will protect all remote refs that are going to be updated by requiring their current value to be the same as the remote-tracking branch we have for them.\n>\n> The problem is people sometimes run \"git fetch\".   And so \"git push\n> --force-with-lease\" is going to do the push even if the local version\n> is stale.\n>\n> Instead I think the default behavior should require that the remote\n> ref's current value be equal to the merge-base of the local-branch and\n> remote-tracking-branch.\n>\n> Here's an example (password is \"test\" for the push):\n>\n> git clone http://test@vm.bit-booster.com/bitbucket/scm/bb/a.git\n> cd a\n> git checkout bugfix/TKT-123\n> git reset --hard HEAD~1   (to simulate situation where local is stale,\n> but remote is up to date)\n>\n> At this point \"git push --force-with-lease\" is going to work.   But I\n> think it shouldn't.   (Note: I use push.default = simple).\n>\n> Here's how I think it should work:\n>\n> git push --force-with-lease=bugfix/TKT-123:$(git merge-base HEAD\n> origin/bugfix/TKT-123)\n> To http://vm.bit-booster.com/bitbucket/scm/bb/a.git\n>  ! [rejected]        bugfix/TKT-123 -> bugfix/TKT-123 (stale info)\n>\n>\n> For now I'm happy with this alias:\n>\n> git config --global alias.please '!sh -c \"git push\n> --force-with-lease=$(git rev-parse --abbrev-ref HEAD):$(git merge-base\n> HEAD @{u})\"'\n>\n\nNevermind!   I realize this essentially removes the \"--force\" and\nturns it into the original non-forced \"fast-forwardable\" only style\npush.   [BLUSH!]\n\nI wonder if there's anything one could do to help those who type \"git\nfetch\" and still want to enjoy \"--force-with-lease\"...\n\n\n> But I'd like to put together a patch if people are interested in a\n> tweak like this to the --force-with-lease default behaviour.  I\n> haven't written much C in my life, but thought this might make a good\n> force-myself-to-learn-C exercise.\n>\n>\n> - Sylvie Davies\n>\n> ps.  I never thought about the fetch problem with --force-with-lease\n> until reading https://developer.atlassian.com/blog/2015/04/force-with-lease/\n> and https://buddyreno.me/git-please-a182f28efeb5#.s291gh5jn , so\n> thanks to them!\n"},{"id":"308930","messageId":"xmqq37gu4m5u.fsf@gitster.mtv.corp.google.com","threadId":"44814","inReplyTo":"CAAj3zPx4uMXhV7t86Cnn8SgmpXb2SGththYN7sHetOqL_JosMg@mail.gmail.com","subject":"Re: RFC: --force-with-lease default behaviour","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-07T21:04:13Z","receivedAt":"2017-01-07T21:04:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"G. Sylvie Davies\" <sylvie@bit-booster.com> writes:\n\n> I wonder if there's anything one could do to help those who type \"git\n> fetch\" and still want to enjoy \"--force-with-lease\"...\n\nThe entire idea behind \"force-with-lease\" is that you plan to later\nforce update the tip of a branch at the remote to replace the commit\nthat used to be at the tip at some point, that you do not want other\npeople to have their own work on that branch that will be lost by\nyour later force-pushing, yet you cannot \"lock\" a branch at the\nremote repository remotely because that goes against the distributed\nnature of the development.  Instead of locking others out, forcing\nothers to wait and sit idle while you complete the material to be\nforce-pushed (which may never happen), you base your work on one\nstate of the remote branch, and make sure the remote branch hasn't\nadvanced in the meantime (or you redo your work)---the cost of the\nextra work due to your planned force-pushing is beared by you, not\nby others.\n\nThere however is no place in Git where you explicitly declare \"this\nis where I start working on producing a new commit.  That commit\nwill replace this state and will not fast-forward from it.\" and\nstore it locally.  The \"--force-with-lease\" was designed to take\nthat information from the command line, expecting that the script\nthat drives it does something like\n\n\t#!/bin/sh\n\tLEASE=$(git rev-parse --verify @{u})\n\t# do whatever that requires non-fast-forward push\n\tgit commit --amend ...\n\t... maybe more ...\n\t# finally push it out\n\tgit push --force-with-lease $LEASE ...\n\nLazy people decided that as long as they promise to themselves that\nthey are not going to do anything to cause @{u} to move, they can\nuse it as a lazy-man's approximate.  Perhaps that was a misguided\nattempt to add convenience.\n\nA possible answer to your wordering may be to deprecate the\ndefaulting to @{u} and always require the expected commit to be\nspecified explicitly.\n\n\n"}]}