{"thread":{"id":"49210","subject":"Would a config var for --force-with-lease be useful?","startedAt":"2018-08-24T16:39:41Z","lastAt":"2018-08-28T09:59:29Z","messageCount":9,"participants":["Scott Johnson","Constantin Weißer","Junio C Hamano","Ævar Arnfjörð Bjarmason","Johannes Schindelin","Phillip Wood"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"356477","messageId":"CAEFop40OJ5MRwM8zxE44yB0f2Fxw9YsUdM1e-H=Nn9e=sAGJ=w@mail.gmail.com","threadId":"49210","inReplyTo":null,"subject":"Would a config var for --force-with-lease be useful?","fromName":"Scott Johnson","fromEmail":"jaywir3@gmail.com","sentAt":"2018-08-24T16:39:27Z","receivedAt":"2018-08-24T16:39:41Z","isPatch":false,"sender":{"key":"jaywir3@gmail.com","avatar":"https://gravatar.com/avatar/9627800ffd11d60e29728cfb9ba14f64bff137ee7cad29b374213663ea060e70?d=mp&s=160"},"body":"Hello Everyone:\n\nI'm considering writing a patch that adds a configuration variable\nthat will allow the user to default the command:\n\ngit push --force\n\nto:\n\ngit push --force-with-lease\n\nAs discussed here:\n\nhttps://stackoverflow.com/questions/30542491/push-force-with-lease-by-default\n\nNow, I understand that there are downsides to having this enabled,\nnamely that a user who has this enabled might forget that they have it\nenabled, and, as such, on a machine that _doesn't_ have it enabled (of\nwhich they are unfamiliar) might then run the more consequential\ncommand \"git push --force\", but my thinking is that adding this as a\nfeature to the git codebase as an _optional_ (i.e. not enabled by\ndefault) configuration variable would then save some of us who use a\n\"rebase-then-force-push for pull request\" workflow some time and\nheadaches.\n\nOf course, I don't want to submit a patch if this is a feature that\nisn't likely to be accepted, so I wanted to get some thoughts from the\nmailing list regarding this idea.\n\nThank you,\n\n~Scott Johnson\n"},{"id":"356520","messageId":"153520405068.637.7595973048355361242@cwe","threadId":"49210","inReplyTo":"CAEFop40OJ5MRwM8zxE44yB0f2Fxw9YsUdM1e-H=Nn9e=sAGJ=w@mail.gmail.com","subject":"Re: Would a config var for --force-with-lease be useful?","fromName":"Constantin Weißer","fromEmail":"i7c@posteo.de","sentAt":"2018-08-25T13:34:10Z","receivedAt":"2018-08-25T13:34:15Z","isPatch":false,"sender":{"key":"i7c@posteo.de","avatar":null},"body":"I think there are two aspects to using \"force with lease\".\n\nFirstly, you, a person aware of the option, using it. In this case I\nthink an alias is very fitting, because you get quickly used to just\ntyping `git pf` or so. Plus, you don't have the disadvantage you\ndescribed: if you’re working on a machine without your alias, you’ll\njust notice immediately and type the full option.\n\nThe other aspect is working in a team. The problem there is, that most\n(at least in my surroundings) use plain --force and you have to make\nthem aware of --force-with-lease. But with an option or an alias, you\ndepend on them using force with lease instead of plain force, so again I\ndon't really see the advantage of such an option.\n\nAnd lastly, a question: say you are using your proposed option and it is\nturned on. Now, git refuses to push, you clarify the situation and\nactually mean to push --force now. How would you do this? 1) turn off 2)\npush 3) turn option on again?\n\nRegards,\nConstantin\n\nQuoting Scott Johnson (2018-08-24 18:39:27)\n> Hello Everyone:\n> \n> I'm considering writing a patch that adds a configuration variable\n> that will allow the user to default the command:\n> \n> git push --force\n> \n> to:\n> \n> git push --force-with-lease\n> \n> As discussed here:\n> \n> https://stackoverflow.com/questions/30542491/push-force-with-lease-by-default\n> \n> Now, I understand that there are downsides to having this enabled,\n> namely that a user who has this enabled might forget that they have it\n> enabled, and, as such, on a machine that _doesn't_ have it enabled (of\n> which they are unfamiliar) might then run the more consequential\n> command \"git push --force\", but my thinking is that adding this as a\n> feature to the git codebase as an _optional_ (i.e. not enabled by\n> default) configuration variable would then save some of us who use a\n> \"rebase-then-force-push for pull request\" workflow some time and\n> headaches.\n> \n> Of course, I don't want to submit a patch if this is a feature that\n> isn't likely to be accepted, so I wanted to get some thoughts from the\n> mailing list regarding this idea.\n> \n> Thank you,\n> \n> ~Scott Johnson\n"},{"id":"356602","messageId":"xmqqin3vk3yv.fsf@gitster-ct.c.googlers.com","threadId":"49210","inReplyTo":"CAEFop40OJ5MRwM8zxE44yB0f2Fxw9YsUdM1e-H=Nn9e=sAGJ=w@mail.gmail.com","subject":"Re: Would a config var for --force-with-lease be useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-08-27T19:24:24Z","receivedAt":"2018-08-27T19:24:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Scott Johnson <jaywir3@gmail.com> writes:\n\n> Hello Everyone:\n>\n> I'm considering writing a patch that adds a configuration variable\n> that will allow the user to default the command:\n>\n> git push --force\n>\n> to:\n>\n> git push --force-with-lease\n\nI actually consider \"--force-with-lease\" that does not say \"this is\nwhat exactly I am expecting to replace with my version\" a fairly\ndangerous form to recommend to the general public, unless their use\nof \"git fetch\" (or \"git pull\") is disciplined.  In the extreme case,\nif you habitually do \"git fetch origin\" only to update the remote\ntracking branches (so that you can do things like \"git log ..origin\"\nto see what others have been doing while you were offline), using\n\"--force-with-lease\" offers no value over \"--force\", as you're\nlikely to find your remote-tracking ref to be up-to-date, but it no\nlonger is what you based on your decision that replacing the tip\nwith your version is safe.\n\nSo, from that point of view, I would recommend thinking twice before\nconsidering to add such a configuration variable.\n"},{"id":"356608","messageId":"87o9dnegxi.fsf@evledraar.gmail.com","threadId":"49210","inReplyTo":"xmqqin3vk3yv.fsf@gitster-ct.c.googlers.com","subject":"Re: Would a config var for --force-with-lease be useful?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-08-27T19:40:57Z","receivedAt":"2018-08-27T19:41:02Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Aug 27 2018, Junio C Hamano wrote:\n\n> Scott Johnson <jaywir3@gmail.com> writes:\n>\n>> Hello Everyone:\n>>\n>> I'm considering writing a patch that adds a configuration variable\n>> that will allow the user to default the command:\n>>\n>> git push --force\n>>\n>> to:\n>>\n>> git push --force-with-lease\n>\n> I actually consider \"--force-with-lease\" that does not say \"this is\n> what exactly I am expecting to replace with my version\" a fairly\n> dangerous form to recommend to the general public, unless their use\n> of \"git fetch\" (or \"git pull\") is disciplined.  In the extreme case,\n> if you habitually do \"git fetch origin\" only to update the remote\n> tracking branches (so that you can do things like \"git log ..origin\"\n> to see what others have been doing while you were offline), using\n> \"--force-with-lease\" offers no value over \"--force\", as you're\n> likely to find your remote-tracking ref to be up-to-date, but it no\n> longer is what you based on your decision that replacing the tip\n> with your version is safe.\n>\n> So, from that point of view, I would recommend thinking twice before\n> considering to add such a configuration variable.\n\nLast year there was a proposal for such a patch in:\nhttps://public-inbox.org/git/1499116727-757-1-git-send-email-f@mazzo.li/\n\nThis was after/during a long discussion starting with:\nhttps://public-inbox.org/git/CACBZZX7MeX-6RHgh2Fa9+YL03mjxs8xmyE86HnVxBxjMYizcig@mail.gmail.com/\n\nIt appears the only patch that got in from that discussion was my\nf17d642d3b (\"push: document & test --force-with-lease with multiple\nremotes\", 2017-04-19) (https://github.com/git/git/commit/f17d642d3b)\n\nI still think something like such a config variable would be useful, as\nnoted in https://public-inbox.org/git/8760f4bmig.fsf@gmail.com/ Junio\nvoiced similar objections at the time.\n\nIt would be great to have some patch like this for consideration, but\ngive that thread a read first to see what some of the objections were /\nvarious points raised for/against doing that.\n"},{"id":"356618","messageId":"xmqqlg8rinbz.fsf@gitster-ct.c.googlers.com","threadId":"49210","inReplyTo":"87o9dnegxi.fsf@evledraar.gmail.com","subject":"Re: Would a config var for --force-with-lease be useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-08-27T20:09:04Z","receivedAt":"2018-08-27T20:09:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> This was after/during a long discussion starting with:\n> https://public-inbox.org/git/CACBZZX7MeX-6RHgh2Fa9+YL03mjxs8xmyE86HnVxBxjMYizcig@mail.gmail.com/\n>\n> It appears the only patch that got in from that discussion was my\n> f17d642d3b (\"push: document & test --force-with-lease with multiple\n> remotes\", 2017-04-19) (https://github.com/git/git/commit/f17d642d3b)\n\nThanks for pointing at the old thread.\n\nAs far as our documentation is concerned, the invitation to improve\nthe situation, offered in \"git push --help\", is still valid:\n\n    Note that all forms other than `--force-with-lease=<refname>:<expect>`\n    that specifies the expected current value of the ref explicitly are\n    still experimental and their semantics may change as we gain experience\n    with this feature.\n\nBut I do not think (and I did not think back then) there is a magic\nbullet to make the lazy force-with-lease automatically safe for\neverybody, so it may be time to declare that the lazy force-with-lease\nwas a failed experiment and move on, with a patch like the one\nsuggested last year in the message:\n\n  https://public-inbox.org/git/xmqq37a9fl8a.fsf_-_@gitster.mtv.corp.google.com/\n\n"},{"id":"356628","messageId":"87k1obee0f.fsf@evledraar.gmail.com","threadId":"49210","inReplyTo":"xmqqlg8rinbz.fsf@gitster-ct.c.googlers.com","subject":"Re: Would a config var for --force-with-lease be useful?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-08-27T20:44:00Z","receivedAt":"2018-08-27T20:44:04Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Aug 27 2018, Junio C Hamano wrote:\n\n[Scott, I hope you're still with us despite your recent attempt to\nunsubscribe from git@ :)]\n\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> This was after/during a long discussion starting with:\n>> https://public-inbox.org/git/CACBZZX7MeX-6RHgh2Fa9+YL03mjxs8xmyE86HnVxBxjMYizcig@mail.gmail.com/\n>>\n>> It appears the only patch that got in from that discussion was my\n>> f17d642d3b (\"push: document & test --force-with-lease with multiple\n>> remotes\", 2017-04-19) (https://github.com/git/git/commit/f17d642d3b)\n>\n> Thanks for pointing at the old thread.\n>\n> As far as our documentation is concerned, the invitation to improve\n> the situation, offered in \"git push --help\", is still valid:\n>\n>     Note that all forms other than `--force-with-lease=<refname>:<expect>`\n>     that specifies the expected current value of the ref explicitly are\n>     still experimental and their semantics may change as we gain experience\n>     with this feature.\n>\n> But I do not think (and I did not think back then) there is a magic\n> bullet to make the lazy force-with-lease automatically safe for\n> everybody, so it may be time to declare that the lazy force-with-lease\n> was a failed experiment and move on, with a patch like the one\n> suggested last year in the message:\n>\n>    https://public-inbox.org/git/xmqq37a9fl8a.fsf_-_@gitster.mtv.corp.google.com/\n\nWith the benefit of hindsight I still agree with my counter-argument to\nthat in https://public-inbox.org/git/8760f4bmig.fsf@gmail.com/\n\nI.e. making plain --force-with-lease harder to use by hiding it behind a\nconfig option gives the user fewer options than with --force to recover.\n\nSo I think we should still recommend the longer and even safer variants\nof --force-with-lease, but being guaranteed to have the SHA-1 you just\nclobbered locally is *better*, and allows us to e.g. do this:\n\n    $ git push --force-with-lease\n    hint: You just clobbered <X> on <remote with <Y>. If you regret\n    hint: this you can (until the object gets pruned) do:\n    hint:     git push <remote> --force-with-lease=<refname>:<Y>\n\nOr, doing the same with --force with some config option to use the\nmarginally safer (because at least you have a local copy)\n--force-with-lease automatically.\n"},{"id":"356629","messageId":"nycvar.QRO.7.76.6.1808272306271.73@tvgsbejvaqbjf.bet","threadId":"49210","inReplyTo":"153520405068.637.7595973048355361242@cwe","subject":"Re: Would a config var for --force-with-lease be useful?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-08-27T21:21:14Z","receivedAt":"2018-08-27T21:21:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 25 Aug 2018, Constantin Weißer wrote:\n\n> I think there are two aspects to using \"force with lease\".\n\nThere is a third, very, very important aspect.\n\nWhen you use --force-with-lease (and I, for one, do, all the time), keep\nin mind that it assumes that you are at least aware of the latest fetched\nref.\n\nLet's add a little color to this, to make it less theoretical, and more\nrelateable. Let's assume that you work on a branch, say,\n`make-this-thing-work`, and you have to work on this branch on two\ndifferent machines, because it is a finicky thing you need to make work.\nLet's add even more color by saying that one of your machines is a windows\nmachine, and the other one an old IRIX machine. We will call them\n`windoze` and `irixxx`.\n\nThe common use case for `--force-with-lease`, at least as far as I know,\nis that this branch is pushed from one of these setups first, say,\n`windoze`, and fetched on the other, then a fixup is necessary and you\nrebase the branch with `--autosquash` to make it compile on IRIX, and then\nyou push with `--force-with-lease` a day later, just in case that you\nforgot to re-fetch something that you did on the `windoze` machine.\n\n(Something like this happened to me recently, where one of my branches did\nnot compile in a Linux VM with an older cURL, and I had to fix a\nWindows-targeting branch to keep it cross-platform)\n\nThe `--force-with-lease` option helps here, and quite a bit.\n\nIt would totally lose its usefulness, though, if you use a tool that\nauto-fetches those remote branches. For example, \"synchronizing\" in\n<name-your-favorite-git-gui-here>.\n\nIn that case, you did not see what was fetched, and you might have missed\nupdates, and you will overwrite them, even if you tried to be careful by\nusing `--for-ce-with-lease`.\n\nI proposed, a couple of months ago, to either fix `--force-with-lease`, or\nto deprecate it in favor of a new option, with a new behavior. The new\nbehavior would look at the *reflog*, much as the `--fork-point` option of\n`git rebase`: in addition to the regular `--force-with-lease` server-side\nchecks, a client-side check *first* verifies that the remote-tracking\nbranch is reachable at least from *one* of the items in the reflog of the\nbranch we are about to push.\n\nThat is, it would ensure that even if we rebased locally, we did\nincorporate the tip commit of the remote-tracking branch, at some stage.\n\nGranted, there are probably cases where you would fetch, look at the\nremote-tracking branch, and reject those changes without integrating those\ninto the local branch. In that case, you would want to relax to the\ncurrent behavior of `--force-with-lease`. But I would expect that to\nhappen only rarely.\n\nThe safety by the proposed behavior would make it a lot easier to accept a\nconfig setting that makes this the default.\n\nI guess that is the reason why that config setting does not exist yet: we\nwould want to have that new behavior in place first...\n\nCiao,\nJohannes\n\n> \n> Firstly, you, a person aware of the option, using it. In this case I\n> think an alias is very fitting, because you get quickly used to just\n> typing `git pf` or so. Plus, you don't have the disadvantage you\n> described: if you’re working on a machine without your alias, you’ll\n> just notice immediately and type the full option.\n> \n> The other aspect is working in a team. The problem there is, that most\n> (at least in my surroundings) use plain --force and you have to make\n> them aware of --force-with-lease. But with an option or an alias, you\n> depend on them using force with lease instead of plain force, so again I\n> don't really see the advantage of such an option.\n> \n> And lastly, a question: say you are using your proposed option and it is\n> turned on. Now, git refuses to push, you clarify the situation and\n> actually mean to push --force now. How would you do this? 1) turn off 2)\n> push 3) turn option on again?\n> \n> Regards,\n> Constantin\n> \n> Quoting Scott Johnson (2018-08-24 18:39:27)\n> > Hello Everyone:\n> > \n> > I'm considering writing a patch that adds a configuration variable\n> > that will allow the user to default the command:\n> > \n> > git push --force\n> > \n> > to:\n> > \n> > git push --force-with-lease\n> > \n> > As discussed here:\n> > \n> > https://stackoverflow.com/questions/30542491/push-force-with-lease-by-default\n> > \n> > Now, I understand that there are downsides to having this enabled,\n> > namely that a user who has this enabled might forget that they have it\n> > enabled, and, as such, on a machine that _doesn't_ have it enabled (of\n> > which they are unfamiliar) might then run the more consequential\n> > command \"git push --force\", but my thinking is that adding this as a\n> > feature to the git codebase as an _optional_ (i.e. not enabled by\n> > default) configuration variable would then save some of us who use a\n> > \"rebase-then-force-push for pull request\" workflow some time and\n> > headaches.\n> > \n> > Of course, I don't want to submit a patch if this is a feature that\n> > isn't likely to be accepted, so I wanted to get some thoughts from the\n> > mailing list regarding this idea.\n> > \n> > Thank you,\n> > \n> > ~Scott Johnson\n> "},{"id":"356633","messageId":"xmqqd0u3igtu.fsf@gitster-ct.c.googlers.com","threadId":"49210","inReplyTo":"87k1obee0f.fsf@evledraar.gmail.com","subject":"Re: Would a config var for --force-with-lease be useful?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-08-27T22:29:33Z","receivedAt":"2018-08-27T22:29:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> I.e. making plain --force-with-lease harder to use by hiding it behind a\n> config option gives the user fewer options than with --force to recover.\n\nI agree with that.  But I would consider it a good thing, if done\nproperly (i.e. suggest --force-with-lease that is not a lzzy form).\n\n> So I think we should still recommend the longer and even safer variants\n> of --force-with-lease, but being guaranteed to have the SHA-1 you just\n> clobbered locally is *better*, and allows us to e.g. do this:\n>\n>     $ git push --force-with-lease\n>     hint: You just clobbered <X> on <remote with <Y>. If you regret\n>     hint: this you can (until the object gets pruned) do:\n>     hint:     git push <remote> --force-with-lease=<refname>:<Y>\n\nUntil the object gets pruned, and until somebody else pushes there\nto make the damage bigger, you can recover from a mistake with that\ninformation.  It probably is a bug that the lazy force-with-lease\ndoes not report what the remote tip you just overwrote was, and this\nwould help great deal.  It would be a good place to start.\n\nOne thing that I am still not clear how this line of thought truly\nwould help users is how to help them decide their answer to \"If you\nregret this\".  An unthinking naïve user would say \"of course I meant\nit when I gave the option---why do you think I regret it?\" without a\nbit more hint, namely, \"<Y> was taken from the remote tracking\nbranch, are you sure that is still what the newly prepared contents\nyou built to replace?  Did somebody clobber it while you are not\nwatching?\"\n\nThese three lines however will be felt too loud by those who would\nmost benefit from them (i.e. those who do not know why they need\nprotection); I do not think advise.* to allow them to be squelched\nwould be appropriate.\n"},{"id":"356658","messageId":"b5b1987e-d761-64c5-a58e-6863bb80d848@talktalk.net","threadId":"49210","inReplyTo":"nycvar.QRO.7.76.6.1808272306271.73@tvgsbejvaqbjf.bet","subject":"Re: Would a config var for --force-with-lease be useful?","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2018-08-28T09:59:22Z","receivedAt":"2018-08-28T09:59:29Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Johannes\n\nOn 27/08/18 22:21, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sat, 25 Aug 2018, Constantin Weißer wrote:\n> \n>> I think there are two aspects to using \"force with lease\".\n> \n> There is a third, very, very important aspect.\n> \n> When you use --force-with-lease (and I, for one, do, all the time), keep\n> in mind that it assumes that you are at least aware of the latest fetched\n> ref.\n> \n> Let's add a little color to this, to make it less theoretical, and more\n> relateable. Let's assume that you work on a branch, say,\n> `make-this-thing-work`, and you have to work on this branch on two\n> different machines, because it is a finicky thing you need to make work.\n> Let's add even more color by saying that one of your machines is a windows\n> machine, and the other one an old IRIX machine. We will call them\n> `windoze` and `irixxx`.\n> \n> The common use case for `--force-with-lease`, at least as far as I know,\n> is that this branch is pushed from one of these setups first, say,\n> `windoze`, and fetched on the other, then a fixup is necessary and you\n> rebase the branch with `--autosquash` to make it compile on IRIX, and then\n> you push with `--force-with-lease` a day later, just in case that you\n> forgot to re-fetch something that you did on the `windoze` machine.\n\nI have this workflow scripted to sync between my desktop and laptop and \nuse it a lot.\n\n> (Something like this happened to me recently, where one of my branches did\n> not compile in a Linux VM with an older cURL, and I had to fix a\n> Windows-targeting branch to keep it cross-platform)\n> \n> The `--force-with-lease` option helps here, and quite a bit.\n> \n> It would totally lose its usefulness, though, if you use a tool that\n> auto-fetches those remote branches. For example, \"synchronizing\" in\n> <name-your-favorite-git-gui-here>.\n> \n> In that case, you did not see what was fetched, and you might have missed\n> updates, and you will overwrite them, even if you tried to be careful by\n> using `--for-ce-with-lease`.\n> \n> I proposed, a couple of months ago, to either fix `--force-with-lease`, or\n> to deprecate it in favor of a new option, with a new behavior. The new\n> behavior would look at the *reflog*, much as the `--fork-point` option of\n> `git rebase`: in addition to the regular `--force-with-lease` server-side\n> checks, a client-side check *first* verifies that the remote-tracking\n> branch is reachable at least from *one* of the items in the reflog of the\n> branch we are about to push.\n\nI think to be completely safe you only want to check the reflog items \nadded since the last push, you can get that time by walking the reflog \nof the remote branch. (In my script I have to settle for using the hash \nof the last push rather than the time as there are no pretty format \nspecifiers for the reflog dates, just commit and author dates). The \nscript also implements a pull command that will rebase any local changes \nsince the last push on top of the remote changes so long as the local \nchanges are descendants of the last push (i.e rebase --onto $new_remote \n$last_push - I've never been sure if this is the same as using \n--fork-point or not).\n\n> That is, it would ensure that even if we rebased locally, we did\n> incorporate the tip commit of the remote-tracking branch, at some stage.\n> \n> Granted, there are probably cases where you would fetch, look at the\n> remote-tracking branch, and reject those changes without integrating those\n> into the local branch. In that case, you would want to relax to the\n> current behavior of `--force-with-lease`. But I would expect that to\n> happen only rarely.\n> \n> The safety by the proposed behavior would make it a lot easier to accept a\n> config setting that makes this the default.\n\nI agree having this as an option to push would be very useful for this \nsort of work flow.\n\nBest Wishes\n\nPhillip\n\n> \n> I guess that is the reason why that config setting does not exist yet: we\n> would want to have that new behavior in place first...\n> \n> Ciao,\n> Johannes\n> \n>>\n>> Firstly, you, a person aware of the option, using it. In this case I\n>> think an alias is very fitting, because you get quickly used to just\n>> typing `git pf` or so. Plus, you don't have the disadvantage you\n>> described: if you’re working on a machine without your alias, you’ll\n>> just notice immediately and type the full option.\n>>\n>> The other aspect is working in a team. The problem there is, that most\n>> (at least in my surroundings) use plain --force and you have to make\n>> them aware of --force-with-lease. But with an option or an alias, you\n>> depend on them using force with lease instead of plain force, so again I\n>> don't really see the advantage of such an option.\n>>\n>> And lastly, a question: say you are using your proposed option and it is\n>> turned on. Now, git refuses to push, you clarify the situation and\n>> actually mean to push --force now. How would you do this? 1) turn off 2)\n>> push 3) turn option on again?\n>>\n>> Regards,\n>> Constantin\n>>\n>> Quoting Scott Johnson (2018-08-24 18:39:27)\n>>> Hello Everyone:\n>>>\n>>> I'm considering writing a patch that adds a configuration variable\n>>> that will allow the user to default the command:\n>>>\n>>> git push --force\n>>>\n>>> to:\n>>>\n>>> git push --force-with-lease\n>>>\n>>> As discussed here:\n>>>\n>>> https://stackoverflow.com/questions/30542491/push-force-with-lease-by-default\n>>>\n>>> Now, I understand that there are downsides to having this enabled,\n>>> namely that a user who has this enabled might forget that they have it\n>>> enabled, and, as such, on a machine that _doesn't_ have it enabled (of\n>>> which they are unfamiliar) might then run the more consequential\n>>> command \"git push --force\", but my thinking is that adding this as a\n>>> feature to the git codebase as an _optional_ (i.e. not enabled by\n>>> default) configuration variable would then save some of us who use a\n>>> \"rebase-then-force-push for pull request\" workflow some time and\n>>> headaches.\n>>>\n>>> Of course, I don't want to submit a patch if this is a feature that\n>>> isn't likely to be accepted, so I wanted to get some thoughts from the\n>>> mailing list regarding this idea.\n>>>\n>>> Thank you,\n>>>\n>>> ~Scott Johnson\n"}]}